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

Do all-in-one package builds when there are no cyclic dependencies #1166

Closed
snoyberg opened this issue Oct 15, 2015 · 5 comments
Closed

Do all-in-one package builds when there are no cyclic dependencies #1166

snoyberg opened this issue Oct 15, 2015 · 5 comments

Comments

@snoyberg
Copy link
Contributor

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:

  1. When there are cyclic dependencies: act just as we do today
  2. Otherwise: force all test and benchmark dependencies (as requested) to be built before building a package, and then build all necessary components at once.
@meteficha
Copy link
Member

Nice! Just to make sure I understood the implications, the advantages are that:

  • There will be fewer dependencies between packages, thus more opportunity for parallelism.
  • Fewer cabal builds per package will mean less overhead.

Is that correct?

@snoyberg
Copy link
Contributor Author

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

@mgsloan
Copy link
Contributor

mgsloan commented Oct 19, 2015

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

@mgsloan
Copy link
Contributor

mgsloan commented Oct 30, 2015

EDIT: long outdated comment removed. Old text: https://gist.github.com/mgsloan/f2c671cc7ca9f4ecbd07

Other notes:

  • This may also allow us to address this TODO
  • @borsboom mentioned that it seems like there are redundant uses of writeBuildCache. I think this would help consolidate that logic and be able to remove the redundant uses.

mgsloan added a commit that referenced this issue Nov 4, 2015
mgsloan added a commit that referenced this issue Nov 4, 2015
mgsloan added a commit to mgsloan/multi-test-suite that referenced this issue Nov 4, 2015
mgsloan added a commit that referenced this issue Nov 4, 2015
mgsloan added a commit that referenced this issue Nov 8, 2015
mgsloan added a commit that referenced this issue Nov 8, 2015
@mgsloan
Copy link
Contributor

mgsloan commented Nov 12, 2015

Done!

@mgsloan mgsloan closed this as completed Nov 12, 2015
mgsloan referenced this issue Nov 24, 2015
+ 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants