-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hdevtools does not pick up test dependencies #38
Comments
Thanks 😄 I'll see what I can do. If you figure it out please submit a pull request 😊 |
@shell could we just not look at the cabal file at all and use |
^ @schell sorry, wrong mention... |
@sol There's already some other tickets regarding sandbox support, so dropping the current implementation would affect that work as well. I'm guessing that the easiest way to fix this is to add support for test dependencies by parsing the cabal file. @maximkulkin - do you have any input? |
@schell Do you have any other input on where newcomers to hdevtools' source can start looking to implement this functionality? |
@jsantos17 - you can take a look at the work that @maximkulkin has done with regard to cabal sandboxes (https://github.com/schell/hdevtools/commits/master @maximkulkin's changes from Feb 15th 2014 - March 16th 2014). My guess is that hdevtools is only looking at the executable named after the cabal project and not other executables as well. |
I guess the problem is in this line https://github.com/schell/hdevtools/blob/master/src/Cabal.hs#L119: you need to pass --enable-tests option in cfgFlags (along with any other standard or custom options that you have in *.cabal file). |
This patch should fix that: maximkulkin@4806bd9 Just pass extra argument to hdevtools:
|
There still could be situations when this approach won't work. Currently hdevtools merges all options from all enabled artefacts in Cabal file. It could possible be situation when two artefacts have conflicting dependencies. Then, the right thing to do is to figure out for given file which artefact it belongs to. To do that, it is needed to take an artefact root modules (either exposed modules for library artefact, main module for executable artefact, etc) and try traverse all dependencies from current package. Then find which artefact current module/file belongs to and load corresponding artefacts ghc options. This is too much work and IMO could be rarely seen to invest in implementing that. |
@maximkulkin I'll give it a whirl! Thanks! |
@maximkulkin works great. Thank you very much. You just saved me a few hours of my life! I cherry picked your commit on top of Schell's fork. My own fork: https://github.com/jsantos17/hdevtools |
Any news on this issue? I'm currently running into the problem. |
@davidpdrsn - @maximkulkin's changes are merged into my fork. Please tell me if that fixes your issue. |
@schell how can I do that? I'm that experienced with cabal. |
Suffering from the same issue here. Any update on the upstream? |
Same problem. I'm running haskell via stack. Also, the suggested
|
The message you see is from GHC itself, so in order to use "-v" flag you need to pass it via |
Problem still not fixed upstream. @schell : your fork works well for me. For the nix users like myself:
|
@2chilled and @maximkulkin, there's a new effort at https://github.com/hdevtools/hdevtools. |
(this is a bug report / feature request against master of https://github.com/schell/hdevtools /cc @schell)
Currently,
hdevtools
does not pick up test dependencies. Here is a minimal way to reproduce this:The text was updated successfully, but these errors were encountered: