Reuse dependencies between project and tools #12526
Open
+536
−182
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This allows the dependencies of the project to be shared with dev tools, preventing unnecessarily rebuilding dependencies while building a tool if an identical version of the package has already been built or vice versa. This requires storing build artifacts of dependencies of dev tools and the project (when built in the "default" context) in a single directory, since their relative path within the _build directory is part of the key used to cache build artifacts. Previously the build artifacts of a package were placed in a directory named after that package, however since dev tools and the project may depend on different versions of the same package, directories needed to be renamed to avoid collisions. Even if the project and dev tools rely on the same version of some package, it may still need to be rebuilt on occasion due to the presence/absence of depopts, or due to manual modification to lockfiles. For this reason, the directories containing package build artifacts contain in their name, a hash of the contents of the lockfile of the metadata in the package's transitive dependency closure. This change introduces the contents of a "package slug" which is a unique directory name for a package comprising its name, version, and dependency closure hash. The DB type used to store metadata while building packages has been updated to be keyed based on slugs, and to store package metadata for dev tools and the project's default build context in the same table to allow dependencies to be shared. Signed-off-by: Stephen Sherratt <[email protected]>
|
Do you mind rebasing? I'll do a more complete review then. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This allows the dependencies of the project to be shared with dev tools, preventing unnecessarily rebuilding dependencies while building a tool if an identical version of the package has already been built or vice versa.
This requires storing build artifacts of dependencies of dev tools and the project (when built in the "default" context) in a single directory, since their relative path within the _build directory is part of the key used to cache build artifacts. Previously the build artifacts of a package were placed in a directory named after that package, however since dev tools and the project may depend on different versions of the same package, directories needed to be renamed to avoid collisions. Even if the project and dev tools rely on the same version of some package, it may still need to be rebuilt on occasion due to the presence/absence of depopts, or due to manual modification to lockfiles. For this reason, the directories containing package build artifacts contain in their name, a hash of the contents of the lockfile of the metadata in the package's transitive dependency closure.
This change introduces the contents of a "package slug" which is a unique directory name for a package comprising its name, version, and dependency closure hash. The DB type used to store metadata while building packages has been updated to be keyed based on slugs, and to store package metadata for dev tools and the project's default build context in the same table to allow dependencies to be shared.
Fixes #12491