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).
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.
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).
