-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
cargo test --all
ignores different feature sets for different members in a workspace
#3620
Comments
cargo test --all
ignores different feature sets for dependencies.cargo test --all
ignores different feature sets for dependencies
Due to the way Cargo's architected right now, this is going to be extremely difficult to fix, if at all. In general though this is where Cargo requires crates to have features be additive for them to be composable. |
There's two problems here:
|
May be then introduce virtual crates for that? For example if [breaking-features]
change_everything = [] And if somebody enable |
We ran into this as well, but totally with open source deps One crate in workspace
Second crate in workspace
If you alternate between running
We have a workspace with 70 crates in it. Our CI effectively has a loop which effectively runs
Since some random subset of our crates ask for either with features and some don't, running tests for all crates forces us to recompile deps repeatedly, which hurts. Especially since itertools is such a low level dep, it's tough. Our CI feels a lot of pain recompiling the same libraries many times. Looking at our log, for a workspace with 70 crates, we have to recompile itertools 10 different times (which kicks off a chain of recompiles) Any advice on how to improve the situation? |
I think if we included the hashes of all the deps into the metadata for the compiled library, that would improve our problem. At least then the deps would get compiled a max of 2 times in our case, rather than back-n-forth To illustrate, here are the commands for itertools in the two cases (added newlines for readability and redacted some absolute paths)
vs
I don't believe the metadata for itertools should be identical in these two cases because they are clearly linking against different versions of libeither (compiled with different features) This won't help the |
Here is the repro I was working with https://github.com/nipunn1313/cargoissue3620 |
Hashed dependencies of metadata into the metadata of a lib This fixes one part of #3620. To my understanding, the more fundamental fix is more challenging
Reject feature flags in a virtual workspace. This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored. In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work. This could alternatively be a warning, but I think it is better to reject it outright. cc #4753, #3620, #5015, #6195, etc.
cargo test --all
ignores different feature sets for dependenciescargo test --all
ignores different feature sets for different members in a workspace
If this is about mutually exclusive features, should we close this in favor of #2980 Marking as "propose to close" just so we don't lose track of this in case no one comes back with clarification on that. |
I think this is more like a general usability issue of feature unification, such as #4463. I believe the documentation is way better than it was in 2017, which now it even talks about mutual-exclusive features. #5210 is an issue looking into this problem from the other way round. Should we close all of them and point to #4463 or #2980 instead? |
I think we should merge all of the feature unification issues. Its something I was already planning on doing as part of my sweep through the issues but you are welcome to it. |
close as per discussion above |
Hello, here is a minimal example for this issue.
https://github.com/alekseysidorov/rust_bugs/tree/master/cargo_test_all
Core crate toml:
First dep toml
Second dep toml with different features
And try to run
cargo test --all
in workspace root.It seems that the core has not been rebuilt with the feature set for second dependency
The text was updated successfully, but these errors were encountered: