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 https://github.com/commercialhaskell/stack/issues/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 https://github.com/haskell/cabal/pull/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 https://github.com/commercialhaskell/stack/issues/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, https://github.com/commercialhaskell/stack/issues/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.

[mgsloan]

Good point, I haven't checked whether or not install also has this issue. I believed it was this way because https://github.com/haskell/cabal/issues/2780 specifies copy.

[mgsloan]

This is particularly problematic for stack ghci - the library doesn't get registered if the copy step fails. This means that if there's an executable with a compilation error, you can't load just that executable into ghci :/ . The workaround is also to have the library as a target.

[mgsloan]

In theory, we could now lift this restriction when Cabal >= 1.24

[sjakobi]

In theory, we could now lift this restriction when Cabal >= 1.24

Why not just error out when Cabal < 1.24 is installed and ask users to stack setup --upgrade-cabal?

[mgsloan]

@sjakobi Hmm, decent idea! It seems like stack works fine with Cabal-1.24, but I don't think much scrutiny has been applied there. stack setup --upgrade-cabal will already upgrade to that, though, so it'd better work. I have noted that we should consider having an informational major version upper bound - https://github.com/commercialhaskell/stack/issues/2280#issuecomment-228252051

It should only error out when you actually want to only build some executable targets.

[sjakobi]

@mitchellwrosen has provided an example project in #2366 for which the command stack build stack-issue:lib currently fails but should succeed once this issue is fixed.

[mgsloan]

I thought this made it into Cabal-1.24, but unfortunately, even though the change happened quite a while before that release, it is not included.

Unless we have some reason to believe a version of Cabal will have this fixed in the near future (i.e. before 1.26), instead I am going to look into having stack always use a custom Setup.hs file which hacks around Cabal's deficiencies.

[mgsloan]

Once the next major version of Cabal is released, this can be resolved. The docs on target syntax should be updated accordingly https://docs.haskellstack.org/en/stable/build_command/#target-syntax

[CMCDragonkai]

Is it possible to specify a package build target in the stack.yaml? I have package in extra-deps, that also produces an executable, the executable target has a dependency that is preventing me from resolving to a more recent LTS version.

[mgsloan]

@CMCDragonkai Not currently possible, but certainly worth considering, feel free to open an issue for it.

[stites]

@CMCDragonkai This is a problem for me as well -- I'm winding up having to configure my dependencies based on extra-dep executables.

[snoyberg]

PR #3237 (which is merged into master) allows building individual executables again. If you'd like to test out the functionality, give stack upgrade --git a shot. Since this issue is resolved on master, closing, thanks for the reports.

[saurabhnanda]

I ran into something similar, and want to confirm before posting to Stackoverflow. I have an executable which SHOULD NOT depend on, or build, the library. However, it seems that when I do stack build webservice:exe:autogen it ends up building the library target first. Is the behaviour related to this issue?

executable autogen
  main-is: GenerateModels.hs
  hs-source-dirs:
      scripts
  default-extensions: OverloadedStrings RecordWildCards DataKinds DeriveGeneric FlexibleInstances FlexibleContexts FunctionalDependencies GeneralizedNewtypeDeriving KindSignatures MultiParamTypeClasses TemplateHaskell TypeFamilies TypeSynonymInstances QuasiQuotes ScopedTypeVariables LambdaCase PolyKinds TypeApplications Arrows ConstraintKinds DuplicateRecordFields
  ghc-options: -threaded -rtsopts -with-rtsopts=-N -Wall -O0
  build-depends:
      base
  default-language: Haskell2010

[snoyberg]

That's impossible to avoid, Cabal (at least before 2.0) always builds the
library component

On Sun, Aug 27, 2017, 11:43 AM Saurabh Nanda [e-mail]
wrote:

I ran into something similar, and want to confirm before posting to
Stackoverflow. I have an executable which SHOULD NOT depend on, or build,
the library. However, it seems that when I do stack build
webservice:exe:autogen it ends up building the library target first. Is
the behaviour related to this issue?

executable autogen
main-is: GenerateModels.hs
hs-source-dirs:
scripts
default-extensions: OverloadedStrings RecordWildCards DataKinds DeriveGeneric FlexibleInstances FlexibleContexts FunctionalDependencies GeneralizedNewtypeDeriving KindSignatures MultiParamTypeClasses TemplateHaskell TypeFamilies TypeSynonymInstances QuasiQuotes ScopedTypeVariables LambdaCase PolyKinds TypeApplications Arrows ConstraintKinds DuplicateRecordFields
ghc-options: -threaded -rtsopts -with-rtsopts=-N -Wall -O0
build-depends:
base
default-language: Haskell2010

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/stack/issues/1406#issuecomment-325185226,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB1Iy5cRApCltZkupGFlTChGCUvRjks5scSw1gaJpZM4Gnvbg
.

[saurabhnanda]

That's impossible to avoid, Cabal (at least before 2.0) always builds the

Does this mean that Cabal 2.0+ will fix the unnecessary dependency on the library component? Or are you simply saying that you're sure of the pre-2.0 behaviour and unsure of the post-2.0 behaviour?

[snoyberg]

The latter, though I strongly believe Cabal 2.0 fixed it. We have plans
with the upcoming backpack support to modify Stack to take advantage of
this new functionality.

On Sun, Aug 27, 2017, 11:59 AM Saurabh Nanda [e-mail]
wrote:

That's impossible to avoid, Cabal (at least before 2.0) always builds the

Does this mean that Cabal 2.0+ will fix the unnecessary dependency on the
library component? Or are you simply saying that you're sure of the pre-2.0
behaviour and unsure of the post-2.0 behaviour?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/stack/issues/1406#issuecomment-325186001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB3V_JKHAafeO_VpAIDaF44m_RZMLks5scS_0gaJpZM4Gnvbg
.

[saurabhnanda]

I did a stack upgrade --git and then tried re-building the executable via stack build webservice:exe:autogen and it still tried to build the library component first. So, I guess, Cabal-2.0+ also doesn't solve this.

[mgsloan]

@saurabhnanda Even if Cabal 2.0 has fixed the issue, there will need to be some changes to stack to fully fix the problem - https://github.com/commercialhaskell/stack/issues/3653 should definitely be looked into soon.