Add support for --features and --no-default-features flags in workspace builds

[newpavlov]

When using cargo cmd --all --no-default-features on virtual manifest cargo should disable default features for all crates in the workspace. cargo cmd --all --features feature1,feature2 should enable feature if crate in the workspace has it and ignore it otherwise.

Old issue text:
In RustCrypto/hashes xargo is used in CI to verify if all crates are indeed no_std. But with the addition of std feature (see branch digest_v0.8) which per convention is enabled by default, xargo does not work correctly anymore. I've changed CI config to use the following command on workspace (Travis build):

xargo build --all --no-default-features --verbose --target armv7-unknown-linux-gnueabihf

But it fails with this error:

error[E0463]: can't find crate for `std`
  |
  = note: the `armv7-unknown-linux-gnueabihf` target may not be installed

It looks like that problem originates from the fact that cargo does not propagate --no-default-features when it builds all crates in workspace. In this particular case it causes digest (and all other crates) to be built with enabled std feature which is quite undesirable.

Is this behaviour intentional? In my opinion this flag (and others?) should be propagated to all crates in the workspace on which subcommand is called.

Old xargo issue.

[est31]

The way serde_bytes, which depends on serde, and which both have optional no_std support, is doing it is via the following setup:

[features]
default = ["std"]
std = ["serde/std"]

[dependencies]
serde = { version = "1.0", default-features = false }

[newpavlov]

@est31
I am not sure why you wrote it here, as you can see for example here RustCrypto/hashes uses the same approach. (std feature in digest crate is disabled by default to simplify configuration a bit)

[est31]

@newpavlov oh I see. nvm then :)

[alexcrichton]

I think this is either a bug or a feature depending on how you look at it, right now the feature selection applies to a "root crate" (which doesn't have much meaning any more really) rather than all crates (aka if you specify --feature foo --all how would we interpret it where it works?)

In that sense this is sort of working as expected, albeit surprisingly.

[newpavlov]

aka if you specify --feature foo --all how would we interpret it where it works?

I think intuitive behaviour in this case will be to enable feature if crate in the workspace has it and ignore otherwise. At the very least if cargo does not support working with features when building workspace (aka virtual manifest) in my opinion it should display warning/error, as currently it's essentially ignores feature related flags.

[nbigaouette-eai]

Instead of disabling all features with --no-default-features, I need to enable a specific feature using --features foo, which is not possible right now when I put my crates in a workspace. :(

[ishitatsuyuki]

Duplicate of #5015.

[est31]

@ishitatsuyuki I'd say that that bug is a dupe of this one, no? Because the other bug has been filed later.

[ishitatsuyuki]

@est31 I'm in favour of using #5015 because that one has a clearer title. This bug affects --features, not only --no-default-features.

[newpavlov]

I've updated issue title and text.

[est31]

@ishitatsuyuki I see, that's a point.

[ishitatsuyuki]

Well, given that the title is updated, feel free to close #5015.

[norru]

So, just stumbled upon this problem.

What is the recommended workaround?

[photex]

I am likewise being bitten by this issue. It isn't clear how to properly work with features when you have a rather large workspace already in place. :D

[photex]

In fact... none of my intuition has even lead me to a solution. If I have a crate in a workspace that must use a feature in order to build, unless I specify a default feature set then I'm unable to build my workspace now.

Specifying a default feature is a bad idea in this case, because if a developer wants to work on this crate, they can't use --no-default-features to override the default in order to work with the other features.

In my particular case the features are determining which graphics api to use, which means that any developers on osx wouldn't be able to develop or contribute to this project without unnecessary trouble.

[Ponewor]

Any progress? This is really counterintuitive right now.

[weihanglo]

package-features has been stabilized since 1.51. The member/feature syntax can be used to enable features defined in member packages.

cargo build --features member/feature

https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options
https://doc.rust-lang.org/cargo/reference/features.html#resolver-version-2-command-line-flags