Please reconsider RUSTFLAGS for setting the backend

[Novum]

I ran into issues with this because I had RUSTFLAGS set via env and it overwrites the ones set in the config.toml target. That makes for some very non-intuitive errors.

Why isn't this just controlled via features?

[josephlr]

Why isn't this just controlled via features?

The main reason we don't "just" use crate features for selecting the backend is twofold:

• Crate Features cannot be enabled/disabled on a per-platform basis (see Platform target-specific features rust-lang/cargo#1197), while enabling/disabling backends is a fundamentally per-platform thing (most of the opt-in backends will only work with certain platforms).
• Changing the backend used by getrandom can silently compromise the security of a program, but crates deep in your dependency tree can set arbitrary features on any crate, meaning that we had to take many convoluted steps in v0.2 to prevent backends from being enabled in most cases.

Combined, these limitations made it very difficult to use Cargo features for backend selection in v0.2, which is why we switched to using RUSTFLAGS in v0.3 (you can see all the problems by searching the closed bugs in the issue tracker).

I ran into issues with this because I had RUSTFLAGS set via env and it overwrites the ones set in the config.toml target.

While this is documented behavior of cargo, I agree that it's quite unintuitive (I thought they were additive until you brought this up). We can add a note to the documentation linked by our error messages to include this corner case. However, you should probably file an issue with Cargo upstream to properly warn when this happens.

[newpavlov]

I am in agreement with @josephlr here. While I agree that compilation flags in Rust are unfortunately unintuitive and somewhat error-prone, but it's the most fitting tool we have right now for the reason stated above. Hopefully, one dat we will get declarative crate configuration flags (a.k.a mutually exclusive or global features, e.g. see this proposal), but until then we are likely to continue to rely on configuration flags. And we certainly will not change it in a v0.3 release since it would be a breaking change.

[alice-i-cecile]

FYI, Bevy is very reluctant to upgrade to the latest version because of the new difficulties here. See bevyengine/bevy#18047 for more discussion. If there's anything we can do, or specific feedback we can offer, please get in touch :)

[josephlr]

Thanks for the heads up @alice-i-cecile I'll comment on that issue.