Skip to content
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

stack 0.1.8 lost ability to build individual executables or library #1406

Closed
ghorn opened this issue Nov 23, 2015 · 25 comments
Closed

stack 0.1.8 lost ability to build individual executables or library #1406

ghorn opened this issue Nov 23, 2015 · 25 comments

Comments

@ghorn
Copy link

@ghorn ghorn commented Nov 23, 2015

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
Copy link
Contributor

@mgsloan mgsloan commented Nov 23, 2015

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
Copy link
Contributor

@massysett massysett commented Nov 28, 2015

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

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Dec 23, 2015

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...

@mgsloan mgsloan modified the milestones: P1: Must, P2: Should Dec 23, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jan 24, 2016

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
Copy link
Author

@ghorn ghorn commented Feb 10, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented Feb 10, 2016

@ghorn Good question.

  1. Once 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 #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
Copy link
Contributor

@snoyberg snoyberg commented Feb 10, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented Feb 10, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented Mar 22, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented May 24, 2016

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

@sjakobi
Copy link
Member

@sjakobi sjakobi commented Jun 22, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented Jun 24, 2016

@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
Copy link
Member

@sjakobi sjakobi commented Jul 14, 2016

@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
Copy link
Contributor

@mgsloan mgsloan commented Aug 12, 2016

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
Copy link
Contributor

@mgsloan mgsloan commented Mar 16, 2017

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
Copy link

@CMCDragonkai CMCDragonkai commented May 20, 2017

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
Copy link
Contributor

@mgsloan mgsloan commented Aug 6, 2017

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

@stites
Copy link

@stites stites commented Aug 24, 2017

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

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Aug 25, 2017

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.

@snoyberg snoyberg closed this Aug 25, 2017
@saurabhnanda
Copy link

@saurabhnanda saurabhnanda commented Aug 27, 2017

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
Copy link
Contributor

@snoyberg snoyberg commented Aug 27, 2017

@saurabhnanda
Copy link

@saurabhnanda saurabhnanda commented Aug 27, 2017

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
Copy link
Contributor

@snoyberg snoyberg commented Aug 27, 2017

@saurabhnanda
Copy link

@saurabhnanda saurabhnanda commented Aug 27, 2017

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
Copy link
Contributor

@mgsloan mgsloan commented Dec 14, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.