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

Comments

Projects
None yet
4 participants
@snoyberg
Contributor

snoyberg commented Oct 15, 2015

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

This comment has been minimized.

Member

meteficha commented Oct 15, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 15, 2015

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Collaborator

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

@borsboom borsboom added the in progress label 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

This comment has been minimized.

Collaborator

mgsloan commented Nov 12, 2015

Done!

@mgsloan mgsloan closed this Nov 12, 2015

mgsloan referenced this issue Nov 24, 2015

Plan build when test components are added #1399
+ 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