-
Notifications
You must be signed in to change notification settings - Fork 845
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
Comments
Yeah, this was an unfortunate consequence of switching from running 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 |
Also, the |
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 |
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 |
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. |
@ghorn Good question.
So, in a way, we're in a corner where there's no good solution. However, we could add a flag like |
What leads you to believe that this will fix things? I've seen this bug appear with |
Good point, I haven't checked whether or not |
This is particularly problematic for |
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 |
@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. It should only error out when you actually want to only build some executable targets. |
@mitchellwrosen has provided an example project in #2366 for which the command |
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. |
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 |
Is it possible to specify a package build target in the stack.yaml? I have package in |
@CMCDragonkai Not currently possible, but certainly worth considering, feel free to open an issue for it. |
@CMCDragonkai This is a problem for me as well -- I'm winding up having to configure my dependencies based on extra-dep executables. |
PR #3237 (which is merged into master) allows building individual executables again. If you'd like to test out the functionality, give |
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
|
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>
.
|
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? |
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>
.
|
I did a |
@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. |
I have two executables, 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? |
@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. |
I have a cabal project with a library and many executables. In stack 0.1.6, I could
to only build the library, or
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.
The text was updated successfully, but these errors were encountered: