default-features = false not working for dependency inside workspace.

[reitermarkus]

Problem

Setting default-features = false for a dependency of one member of a workspace on another workspace member does not work.

Steps

1. Create the following workspace directory structure.

├── Cargo.toml
├── dep
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
└── lib
    ├── Cargo.toml
    └── src
        └── lib.rs

using

echo '[workspace]' > Cargo.toml
echo 'members = ["lib", "dep"]' >> Cargo.toml

cargo new --lib lib
echo 'dep = { path = "../dep", default-features = false }' >> lib/Cargo.toml

cargo new --lib dep
echo '[features]' >> dep/Cargo.toml
echo 'default = ["should_not_be_enabled"]' >> dep/Cargo.toml
echo 'should_not_be_enabled = []' >> dep/Cargo.toml

2. Run cargo build -vv and see that dep is compiled with --cfg 'feature="default"' --cfg 'feature="should_not_be_enabled"'.

Possible Solution(s)

–

Notes

Output of cargo version:

cargo 1.44.0 (05d080faa 2020-05-06)

as well as

cargo 1.46.0-nightly (79c769c3d 2020-06-11)

The same thing also happens if dep is not a workspace member but a plain subdirectory.

Also, the problem does not happen when running cargo build -vv inside of lib after a cd lib.

[ehuss]

Features in a workspace are unified across all roots selected on the command-line. In your example, you have selected both dep and lib with the default features enabled, so it is built with default features.

You can use cargo build -p lib or change into the lib directory and run cargo build or use cargo build --no-default-features -Zpackage-features (see #5364).

The behavior of "workspace features unify based on what is being built" is tracked in #4463.

[reitermarkus]

You're right, in the first case when just running cargo build it basically builds all workspace members, this can indeed be fixed by specifying a specific package using cargo build -p lib.

But this still leaves the case where dep is not a workspace member but just a subdirectory.

[ehuss]

I'm not sure I understand your last comment. Using your example, the following does not select the default features for the dependency:

cargo new foo
cd foo

echo 'dep = { path = "dep", default-features = false }' >> Cargo.toml

cargo new --lib dep
echo '[features]' >> dep/Cargo.toml
echo 'default = ["should_not_be_enabled"]' >> dep/Cargo.toml
echo 'should_not_be_enabled = []' >> dep/Cargo.toml
cargo build -v

[dubiousjim]

I think he means that this still builds dep with --cfg 'feature="should_not_be_enabled"', and the justification about workspace members having their features unified doesn't apply:

echo '[workspace]' > Cargo.toml

# as in original instructions
# except "dep" is no longer a workspace member, merely a subdirectory
echo 'members = ["lib"]' >> Cargo.toml

cargo new --lib lib
echo 'dep = { path = "../dep", default-features = false }' >> lib/Cargo.toml

cargo new --lib dep
echo '[features]' >> dep/Cargo.toml
echo 'default = ["should_not_be_enabled"]' >> dep/Cargo.toml
echo 'should_not_be_enabled = []' >> dep/Cargo.toml

cargo build -v # issued in workspace root

[ehuss]

Ah. Path dependencies are automatically added as workspace members, so it doesn't matter whether or not it is listed.

[dubiousjim]

Oh right.

[reitermarkus]

Path dependencies are automatically added as workspace members

So is this working as intended? It is quite surprising that behaviour changes simply by switching to a path dependency for local debugging.

[ehuss]

For now that is the intended behavior. I would recommend choosing the specific packages you want to build (with -p) if the unification is a problem.

[ehuss]

Closing as this is the intended behavior for now. There are links above to issues tracking things like workspace unification.