Do all-in-one package builds when there are no cyclic dependencies #1166
Comments
Nice! Just to make sure I understood the implications, the advantages are that:
Is that correct? |
I don't know that (1) will happen; actually, the opposite is likely true, though I'm not certain. The second is the real advantage (and avoiding some unfortunately Cabal cases with unnecessarily-overwritten cabal_macros.h). |
I've resolved #1181 with a different approach, so this isn't so urgent. It would be a nice optimization, though. Almost humorously, the only way to work around a different --coverage issue is to build tests one at a time - https://ghc.haskell.org/trac/ghc/ticket/1853#comment:23 (tl;dr; there are problems getting coverage for modules built directly into an executable, when there are multiple executable stanzas). |
EDIT: long outdated comment removed. Old text: https://gist.github.com/mgsloan/f2c671cc7ca9f4ecbd07 Other notes: |
Done! |
+ changes the ensureConfig logic to ignore the list of components, as it does not affect the config of the package. + avoid reconfigures when the new deps are a subset of the old deps
Discussed with @mgsloan already. The current reason for this is dealing with code coverage better, but this should in general make Stack behave better for common cases. (@meteficha, you in particular will probably like this.)
Currently, Stack does a separate
cabal build
for the library/executables, tests, and benchmarks. The reason is cyclic dependencies: package B may depend on package A, while package A's test suite depends on package B. We want to tweak this as follows:The text was updated successfully, but these errors were encountered: