-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Tracking Issue for workspace feature-unification
#14774
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
As for implementing this, I think its ok to implement each config value (and maybe stabilize) separately. For all of this, the top-level function for where all of this lives is cargo/src/cargo/ops/resolve.rs Lines 137 to 269 in e858736
Keep in mind that we have two resolvers (dependency, feature) and multiple phases
To make The big risk is that we do the filtering differently between the the dependency resolver and the feature resolver. As for |
This comment has been minimized.
This comment has been minimized.
### What does this PR try to resolve? Adds workspace feature unification for #14774 ### How should we test and review this PR? In a workspace that has dependencies with different activated features depending on the packages being built, add the `resolver.feature-unification = "workspace"` option to `.cargo/config.toml`. Build the entire workspace with `--workspace` and then build individual packages, ensuring no dependencies are being recompiled. ### Additional information Originally, the RFC and tracking issue mention some more complex changes required in cargo's dependency/feature resolution phases in order to support workspace feature unification. However, it seems like it also works by just modifying the list of `PackageIdSpec`s passed to the workspace resolver to include all workspace members, and then using the original list of specs when generating the build units. I'm wondering if I missed something because this change feels a bit *too* simple... I tested it on a fairly large workspace containing about 100 packages and didn't see any recompilations when building with different sets of packages. I also added an integration test that verifies the correct features are enabled. If there are any other test cases I should include, please let me know and I'll try to add it.
Summary
RFC: #3692
Implementation:
feature-unification = "workspace"
(feat: implement workspace feature unification #15157)feature-unification = "package"
Documentation: TODO
Adds the
resolver.feature-unification
configuration option to control how features are unified across a workspace.Unresolved Issues
Future Extensions
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
The text was updated successfully, but these errors were encountered: