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.

[mgsloan]

Good point, I haven't checked whether or not install also has this issue. I believed it was this way because haskell/cabal#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 - #2280 (comment)

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 ***@***.***> 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 <#1406 (comment)>, 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 ***@***.***> 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 <#1406 (comment)>, 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 - #3653 should definitely be looked into soon.

[aammfe]

I have two executables,
1- a cross platform.
2- only available on linux and mac (bcs its uses unix package)

whenever I try to build it 1 at windows, eg: stack build mypkg:exe:myExe1 it tries to build 2 as well, which ultimately fails the build.

when I can expect this bug to resolve?

[mpilgrem]

@aammfe, the short answer to your question is, I don't know. I am not aware of anyone currently working on the matter. My own understanding of the underlying issue has not moved on since this comment: #5647 (comment). I will ask on the Haskell Community to see if anyone knows if the upstream 'bug' in Cabal was ever resolved.