Use a separate build cache for each component of a package #3750
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.
Please include the following checklist in your PR:
Attempt at a fix for #3732. This introduces a separate build cache for each component of a package, instead of having one for the entire package.
Previously, if a package
foo
was built with tests enabled then the test files (saySpec.hs
) would be recorded in the build cache. With no further source changes, if the dirtiness offoo
is checked in a scenario where we are not asking forfoo
's tests (and so not mentioningSpec.hs
at all), the dirtiness check of the source files would spot thatSpec.hs
is in the build cache but not in the files we want to compile, so a rebuild would be triggered. With this patch, we only compare with the build cache for the relevant component.I think this is a better situation than before, but still not perfect - dirty files are not tracked on a component basis with this, so I think we can still get some useless rebuilds. However, querying dirty files by component looked a bit more involved, and would change much of the
ConstructPlan
module. Apart from it being more complicated, I wasn't sure if I would be stepping on @ezyang's toes with work in there.Please also shortly describe how you tested your change. Bonus points for added tests!
Manual testing based on @snoyberg's example in the linked issue: a project with 2 packages,
foo
andbar
that depends onfoo
, both with test suites.