stack 0.1.8 lost ability to build individual executables or library

[ghorn]

I have a cabal project with a library and many executables. In stack 0.1.6, I could

stack build myproject:lib

to only build the library, or

stack build myproject:myexe1
stack build myproject:myexe2

to build individual executables. When I upgraded to stack 0.1.8 I lost this feature.

Losing this ability makes it take considerably longer to develop with stack, since I usually want to repeatedly rebuild one executable until it works, and having stack build all of them takes a very long time.

$ stack --version
Version 0.1.8.0, Git revision e33dd995e292efcf8ee42e1e4c649b96232abf2e (2603 commits) x86_64

[mgsloan]

Yeah, this was an unfortunate consequence of switching from running install to running copy + register (see #1203). My fix for this was to always build the executables with the library..

I agree this is rather unfortunate. I'm not sure what to do about it, though. Looks like we have a tradeoff between working around a Cabal issue in order to run Setup.hs the same way as cabal install, or support building individual executables. You can try out different alternatives by running stack build -v and copy + pasting the lines that start with Run process:. Note that if you invoke build and omit the executable component, then the copy step will fail...

[massysett]

Also, the :lib target is not documented in doc/build_command.md.

[mgsloan]

Bumping priority, since others are reporting it and it breaks our tutorials #1554 .

Plus, the decision for #1203 seems to be somewhat arbitrary. I think that stack was running postInstall before (via runhaskell Setup.hs install), and this is an arbitrary switch to using postCopy. This needs to be investigated further, though. Things also get tricky because Cabal-1.18 has different postInstall / postCopy behavior...

[snoyberg]

Just weighing in, since I saw this referenced from Reddit. The Cabal bug of erroring out when executables weren't built during copy/install exists regardless of whether we use Setup install or Setup copy, so the change referenced above should have no impact on this.

[ghorn]

How much effort do you estimate this is, and is there anything I can do to help as an outsider? This is making incremental builds extremely painful for my company.

[mgsloan]

@ghorn Good question.

1. Once Per component copy haskell/cabal#3066 is merged and a new version of Cabal is released, we can allow selectively building executables

2. Alternatively, we can revert the decision in Stack doesn't seem to handle projects with custom Setup.hs or submodules well? #1203 , and use install instead of copy + register. This would be a behavior change, though, which will cause some projects which used to successfully build to fail, which is something we'd like to avoid. Thoughts on this, @snoyberg / @borsboom ? Do we want to preserve successful builds for funky projects even if it makes things less pleasant for normal projects?

So, in a way, we're in a corner where there's no good solution. However, we could add a flag like --cabal-setup-install or something, to instead use runhaskell Setup.hs install, and also have this enable building executable components individually. To save you from specifying this with every invocation of stack, #846 can be implemented.

[snoyberg]

Alternatively, we can revert the decision in #1203 , and use install instead of copy + register.

What leads you to believe that this will fix things? I've seen this bug appear with runhaskell Setup.hs install.