Configure specific features to be used for all examples via Cargo.toml

[softstream-link]

Problem

Trying to add

this to my cargo.toml however

[profile.test]
default = ["unittest"]  // feature name
 
[profile.dev]
default = ["unittest"] // feature name

after adding above I am amble to run and compile tests which require "unittest" feature but not able to run anything under "examples" folder which depends on this feature until I add explicit add this

[[example]]
name = "file_name"
required-features = ["unittest"]

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

[weihanglo]

profiles are designed for managing compiler settings, not Cargo features.

profiles.dev.defaults is also not a valid Cargo.toml manifest key at this moment. You shall see this error message if you had that key:

warning: unused manifest key: profile.dev.default

To enable a Cargo feature, use -F/--feature flag. For example, cargo run --example you-example-name -F unittest.

[softstream-link]

Thanks, so there is no way to configure a specific feature to be used for all examples via Cargo.toml?

[weihanglo]

So far as I am aware of, no.

There are some relevant issues/RFCs, but none of them configure features for all examples.

• Cargo target features rfcs#3374
• Automatically enable required-features #4663

Apart from convenience, is there any other reason you'd like to specify the same feature sets for all examples? It would be great if you could share the exact use case of it.

[softstream-link]

Here is my typical scenario

1. I have a package called ./src/unittest - I keep a number of stucts and functions without which setting up a test or a meaningful example or a benchmark is not possible. I am working on a network message library that where you can do send / recv structs instead of byte slices. https://github.com/softstream-link/links.

2. So I protect this module with a feature 'unittest' so that it is not included in the final distribution

3. What I found is that it is not particularly sustainable and consistent to enable this for a test vs example vs benchmark.

test - I have to do by, but then I have to enable default feature to be full and remember to turn it off before publishing otherwise vscode does not enable it for a quick run from IDE

#[test]
#[cfg(feature = "unittest")]
mod test {
 ....
}

example - I have to do by

[[example]]
name = "my_example"
required-features = ["full"] 

benchmark - I have to do by

[[bench]]
name = "my_bench"
harness = false // I use criterion
required-features = ["unittest"]

[weihanglo]

Just read your project a bit. I can see the challenge inside. However, a unit test in Cargo is actually a thing in Rust compiler, specifically libtest in rustc. It's not a separate compilation unit (crate) like examples, integration tests, or benchmarks. That's the difference and I don't think it will change in any near future.

I can also see the inconvenience. One way to avoid the required-features boilderplates is... not writing them at all. The drawback is that your user will have a regressed error message from rustc for missing features flag enabled. Despite that, I'll still recommend specifying required-features and using --features cli options for now.

[weihanglo]

Personally, I tend not to add such a feature, but will leave this open for now to see if people have opinion about configuring cargo targets globally/by “target kind”.

[mahmoud-moursy]

I am developing a TUI no_std library that can optionally have std support. Many examples will fail to compile without the default std feature, because you can't write to stdout without std. It's kind of annoying because some 70% of examples will fail when running cargo doc or cargo test without specifying --all-features constantly.

Additionally, some docs are just not compiled without enabling their feature. Crate authors might see that some docs don't appear because they didn't set package.metadata.docs.rs.all-features, which might be confusing as it's not immediately apparent how to fix it. Adding native support for this in Cargo could help resolve this.

[Systemcluster]

It's kind of annoying because some 70% of examples will fail when running cargo doc or cargo test without specifying --all-features constantly.

You can add your crate to its own dev-dependencies and specify the std feature there.

[epage]

This appears to be a duplicate of #6945 and so I'm closing in favor of that. If there is something I missed, let us know!