Ability to detect profiles

cargo currently supports profiles but it's not possbile to access this information from the code. Example :

inherits = "release"

inherits = "release"

Now I want to make cfg if cfg!(profile = "mycoolotherprofile") { ... }

Another way to do this is to implement feature manually but again there is no way currently to declare a feature for the profile only (or at least not to my knowledge)

What is the proper way to do this? I was told to 'use make and be with it' but I don't want to use tooling outside cargo. I think that this could be a valuable feature in cargo, but the onl proposal on this got closed ( Allow profile to be used in `cfg`s · Issue #3803 · rust-lang/cargo · GitHub ) with no direct answer (they were focused on bench question but this is just one example of what profile could be. We have cfg test in the end).

Could you expand on why making it conditional on profile is the right way to go as compared to --cfg or features?

Because profile can enable something else (for example, profile can enable lto). For example I can have profile.highperf that enables lto=true and say feature allow_unsafe_indexing. In my case I would like it to make it always enabled for this profile.

Maybe a design the other way would be better: allow profiles to enable features, so your [profile.highperf] could have required-features = ["reckless_indexing"]


Since profiles are at the workspace level, it would be very limited what features they can enable.

This also, to me, is a reason against making cfgs for profiles like this as it very much limits where the profiles can be detected. This would also likely not play well with the --check-cfg feature.

Now, global features might do the trick :wink:

To ensure the information known, build scripts have $PROFILE set to debug or release (only) depending on which profile is transitively inherited from, but using this is not recommended; using other more granular indicators set by the profile (e.g. OPT_LEVEL) is preferred.

I would extend this to cfging based on profiles — instead of matching the profile itself, which is more fragile (even if we set a multivalued cfg for the whole inheritance chain, so e.g. profile = "release" and profile = "bench" were both set), key off of something the profile sets.

Setting features from a profile doesn't work well, but I do think setting custom cfgs from profiles could work well. It doesn't break use of --cfg lib_unstable root package opt-in requirement tricks (only the root manifest can define profiles) and it makes it easier to use conventional cfgs than needing to mess with $RUSTFLAGS (e.g. cargo-careful establishes cfg(careful) to turn on extra safety checks over just cfg(debug_assertions)).

Setting custom cfgs are, in a way, a form of semiglobal features, since enabling them via RUSTFLAGS does so globally, and there's no real targeted way to enable them just for certain crates in a compilation graph (except for environment variable plus buildscript shenanigans).

1 Like

Hmm, this sounds like a great idea, but I was unable to enable required-features just for one profile. Could you please elaborate a little bit more?

This is not a real syntax, but a hypothetical alternative proposal.

Ah, my bad. But it would really a big help in this, not automatically generating features but at least requiring them would be really nice.