-
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
Even with resolver=2 features are unified when starting from project root #12139
Comments
Unless I'm misreading something, that is an incomplete statement. What matters is what package is selected and not just the directory
The features are then unified across all selected packages. This is behaving as intended and
Sounds like
That would just be
I'm not quite sure what you mean here. Are you suggesting we error instead? Unfortunately, that is not likely to happen as that would be a breaking change. |
If there was a warning, that would have saved me an hour of debugging. Something like this:
|
A warning would only help a fraction of users and would likely not be able to report the difference in features. We are also very judicious in producing warnings because there is no way to control them. With #12115, we might start introducing more cargo warnings. |
Also, it looks like this is a duplicate of #8157, closing in favor of it. If I missed an aspect that is different, let us kow. |
Problem
Different features of the crate a used depending on how what is the directory we start compilation from.
Steps
Full code is in this repository https://github.com/stepancheg/cargo-features-bug
What it has:
a
,b
,common
common
defines two featuresx
andy
and has a function which prints the featuresa
depends oncommon
with featurex
b
depends oncommon
with featurey
a
has a binary which prints features ofcommon
Steps
cargo run --bin a
from the repository root:cargo run -p a
from the repository root:a
,cargo run -p a
orcargo run --bin a
Which means feature
y
of cratecommon
is activated depending on what is the directory we start compilation from.I don't know if that's expected behavior but it is very unintuitive.
Cargo tree
Additionally,
cargo tree
does not help to debug it. From the repository root if I docargo tree -p a -e features
(which is what I do when I see misbehavingcargo run --bin a
):It does not give any hint that
cargo run --bin a
would enable featurey
.There's no option
cargo tree --bin a
.Possible Solution(s)
Do not use command without explicit
-p
flags from the repository root.Version
The text was updated successfully, but these errors were encountered: