Rebuilding and running an executable installs every executable configured #5974
Comments
|
I noticed this line from the Other binaries are not built, though, because none of them had any relevant source changes. Yet, Stack proceeds to install the binaries as if they were rebuilt. In any case, I don't get the need for rebuilding all binaries in this case. Perhaps someone can explain? |
|
@jeenuv, I can't reproduce this, on Windows. I have a project that looks a lot like a plain First time out, |
|
@mpilgrem, thanks for checking. I forgot to mention that I'm on Linux, but I didn't think that'd matter. However, this is my reproducing this afresh: Ran executables:
foobar1:
main: foobar1/Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- foobar
foobar2:
main: foobar1/Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- foobarFirst run: Nothing surprising here, but then: Notice the installations for both I get rebuilding and wasteful installations if I switch between running FWIW, there's a similar reproducing from a Reddit thread. I hope you'd be able to reproduce as above. |
|
@jeenuv, on the two aspects - (1) 'building' and (2) 'installing' (actually, I think the Cabal library output On the I understand from the documentation for the Cabal library that |
|
Investigating this has, however, revealed something else that is odd on Windows. I've opened a separate issue for that. |
I'd have thought so, but having used If I'm reading this right, there's an attempt to build it; perhaps no compilation occurs thereafter, because there were no source changes. This is different to how Then I see I get the feeling that Stack and the underlying cabal system is operating at different granularity: I, as a Stack user, am asking to only run a single binary (and build if necessary). Stack's translation of that into Cabal tuns out to be "build and install everything". Bringing this to back to my original problem: the install everything approach is workable as long as there are only a couple of binaries involved. If there happens to be more (as with my use case), the situation proves unworkable without resorting to commenting stuff out from But then, if Stack is reliant on cabal for these matters, I don't know if there will be a fix. What would have been a relief is if Stack would tell me where the binary location is, by some variant of |
|
I don't think With I am not across where the boundary between Stack and the Cabal library falls exactly, but I suspect that Stack hands over to the Cabal library to decide what, if anything, needs to be done to 'build'. I am still trying to work out where in Stack's code base the |
You're right - what I may have tried is building the same binary over and over, which of course doesn't do anything. If I switch over to building another binary, it does the full shebang indeed.
That sounds like good news? |
|
Some notes for my own information:
let shouldCopy = not isFinalBuild && (hasLibrary || hasInternalLibrary || hasExecutables)
when shouldCopy $ withMVar eeInstallLock $ \() -> do
announce "copy/register"
eres <- try $ cabal KeepTHLoading ["copy"]
-- * Registers the library and copies the built executables into the
-- local install directory. Note that this is literally invoking Cabal
-- with @copy@, and not the copying done by @stack install@ - that is
-- handled by 'copyExecutables'. |
|
I've just run into this, in a big (proprietary) project with ~15 executables. The bug therefore has a significant impact on our CI times. Is there any hope of a fix? |
|
I think progress on this issue will be related to #6377. That is because (extract): but by GHC 8.4.1 and |
Also updates the online guide to assume the use of new Cabal copy.
|
@jeenuv, @isovector, I think I have fixed this (when specifying GHC versions that come with newer Cabal versions) in #6451. If you are able to test that version of Stack, that would be much appreciated. ( |
Fix #5974 If new Cabal copy is available, use it
General summary/comments
When only a single executable is required to be (re)built, building and running that executable installs all other binaries configured.
Steps to reproduce
Main.hsfor any executable;stack run that_executable;Expected
Since the source changes (step 4 above) affected only a single executable, the reasonable expectation from Stack is that it rebuilds and run that executable alone—do nothing more.
Actual
Instead, as mentioned, Stack installs every executable whenever there is any changes made. This is wasteful and unnecessary.
The back story: was trying my hand at AOC 2022. I configured each day's puzzle as a separate binary, for example, under
app/day12_1andapp/day12_2. Due to the incremental nature of development, every time I make changes today12_2, for example, every other executable is installed beforeday12_2is run. That is 12x2, 24 binary installs when a single executable source was changed! Needless to say, this increases the turn around time. And it gets worse with every passing day, when I keep adding more and more executables.My current work around is to configure one executable at a time, and comment out the rest. I feel shouldn't have to do this. Stack is acting suboptimally. Executables are supposed to be independent of each other; changing one shouldn't cause any action to be taken upon the rest (unless their common dependency changes, which in this case, it didn't).
I believe I've tried all command line options to get Stack to break out of it, but without any success.
Stack version
Version 2.9.1.
Method of installation
Official binary, downloaded via haskellstack.org or from Stack's repository
The text was updated successfully, but these errors were encountered: