Cargo: building workspaces can't use --features flag

[SamPeng87]

i define feature in some sub-create

    [features]
    default=["product","dangerous_configuration"]
    dangerous_configuration=[]
    develop=[]
    product=[]

then,execute cargo cargo build --features="develop"

it can't work,only work in sub-create default features selectors.

cargo build --no-default-features --all not work too

Is it a Bug?

[alexcrichton]

Yes right now [features] is only allowed on individual crates rather than workspace configurations.

[SamPeng87]

Thank your report.Wish this feature can quick complete. I use two [[bin]] point some other needed feature.it is too low.but thank god this can good work.

[SamPeng87]

En..Can I push feature arguments with 'cargo build' pass to sub-creat?like my example. I think that looks very natural

[alexcrichton]

You should be able to do --features foo/bar I think?

[sanmai-NL]

@SamPeng87: could you please test alexcrichton’s suggestion, so that the issue can perhaps be closed?

[Nemo157]

Attempting to reference a feature in a member of a virtual manifest/workspace does not work (testing with cargo 0.26.0-nightly (1d6dfea44 2018-01-26) and almost https://github.com/rust-lang-nursery/futures-rs/commit/2666a72):

.../futures-rs > cargo build --features futures-core/std -p futures-core -v
error: Package `futures-core v0.2.0 (file:///.../futures-rs/futures-core)` does not have these features: `futures-core`

.../futures-rs > cd futures-core

.../futures-rs/futures-core > cargo build --features futures-core/std -p futures-core -v
error: Package `futures-core v0.2.0 (file:///.../futures-rs/futures-core)` does not have these features: `futures-core`

.../futures-rs/futures-core > cargo build --features std -p futures-core -v
   Compiling futures-core v0.2.0 (file:///.../futures-rs/futures-core)
     Running `rustc --crate-name futures_core futures-core/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=314425e352544566 -C extra-filename=-314425e352544566 --out-dir .../futures-rs/target/debug/deps -C incremental=.../futures-rs/target/debug/incremental -L dependency=.../futures-rs/target/debug/deps`
    Finished dev [unoptimized + debuginfo] target(s) in 0.85 secs

Also, --no-default-features does not work in a workspace (note the --cfg 'feature="default"' in the rustc line):

.../futures-rs > cargo build --no-default-features -p futures-core -v
   Compiling futures-core v0.2.0 (file:///.../futures-rs/futures-core)
     Running `rustc --crate-name futures_core futures-core/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=314425e352544566 -C extra-filename=-314425e352544566 --out-dir .../futures-rs/target/debug/deps -C incremental=.../futures-rs/target/debug/incremental -L dependency=.../futures-rs/target/debug/deps`
    Finished dev [unoptimized + debuginfo] target(s) in 0.41 secs

I'm not sure whether there's a good behaviour for these to all have, but if they're not going to apply when building from a virtual manifest then maybe they should warn/error to inform the user?

[Nemo157]

See also #5364, that appears to cover most of the relevant behaviour and should hopefully close this.

[jhpratt]

@alexcrichton Passing a feature flag works for crates in a workspace, but how can one _disable_ a default feature flag?

[alexcrichton]

There is no way to selectively disable on default feature, rather you need to turn them all off with --no-default-features (or default-features = false) and then re-enable the other default features you still need manually

[jhpratt]

It _is_ possible to use the --no-default-featurees flag when building a workspace though? When I tried yesterday it didn't seem to work.

[alexcrichton]

Ah no, not currently, it has to be directed at a package not a workspace

[Manishearth]

You should be able to do --features foo/bar I think?

@alexcrichton this isn't working for me in https://github.com/servo/webxr/ (try --features webxr/ipc, it compiles but doesn't pull in ipc_channel)

This bug is particularly annoying because this forces me to build from a subfolder, but cargo sets the error message root as the workspace root, so i can't click on the errors to have them open in my editor

[Manishearth]

Ah, you can use --manifest-path to make it work (but you don't need to foo/bar it then)

[jonhoo]

I think having --features foo/bar work would still be better though. It would allow you to do things like "run all tests across all subcrates, and keep this feature enabled" without having to explicitly enumerate every crate (handy for things like general-purpose CI scripts).

[nox]

Is there any ongoing work for --features foo/bar? Or guidelines as to where to look at in the code to implement such a thing?

[m4b]

What happened here? This seems like a pretty big usability paper cut; I just refactored into a workspace, and now it's very unpleasant to build...

[paddyhoran]

Ran into this also, the fact that --no-default-features is not applied silently at the workspace level is misleading as CI builds all pass.

[l-x-u]

Would also love this ability.

[nixpulvis]

I'm sure there's a few reasons why this doesn't work, but a naive attempt to use --no-default-features in a workspace lead me here.

I feel like I'd expect a workspace to have effectively the union of the features of it's members. Members could even have the same features and they would be controlled as one. For example, in a workspace with:

[workspace]
members = [
    "foo",
    "bar",
]

I may have the following two manifests:

# foo/Cargo.toml
[features]
default = ["a", "c"]
a = []
b = []
c = []
d = []

# bar/Cargo.toml
[features]
default = ["a", "e"]
a = []
b = []
e = []
f = []

Here I think I'd expect the following:

• cargo ... --no-default-features would disable all of foo/a, foo/c, bar/a and bar/e
• cargo ... --features=b would enable both foo/b and bar/b
• cargo ... --features=f would enable only bar/f

What am I missing? This seems somewhat straightforward. Could I take a stab at implementing this in cargo?

[Recmo]

I'm stuck on this one now too.

Due to a different but related shortcoming I have bench and test features for all packages in the workspace (because dev-dependencies would enable std on some main dependencies, breaking the no-std build). To build it, I would just use cargo test --all-features in the root, because I can not specifically enable the test feature.

But now one of the packages in the workspace has a nightly-only feature, and using --all-features breaks stable.

I'm stuck. Any advice is appreciated.

[gilescope]

Isn't this a dupe of https://github.com/rust-lang/cargo/issues/4753 - can we close this one and continue the discussion there?

[nixpulvis]

@gilescope I tried collecting all the related (possibly duplicate) issues in https://internals.rust-lang.org/t/features-and-workspaces-request-for-meta-issue/11964 hoping to aggregate them. No responses as of yet however.