Compiler command line customization

[brson]

As with the Rust build itself, when distros build and package binaries of Cargo applications, they want to be able to customize all command lines to all compilers.

In the Cargo case this means at least customizing the rustc command line; it's not clear whether Cargo itself needs to provide facilities for customizing CFLAGS, etc. or if that's the responsibility of build scripts.

This requirement seems to be at odds with design goals of the Cargo developers. Design work is needed.

re https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767

[brson]

@alexcrichton and I discussed a potential scheme:

• RUSTFLAGS applies applies to normal builds, not buildscripts and plugins
• RUSTFLAGS_$triple applies to all that match triples (also consider replacing dashing with underscores in the triple ala gcc-rs).
• Don't pass to invocations of rustc that don't pass the triple, like when Cargo does version detection.
• Need to decide whether Cargo picks one or both when multiple apply.

[brson]

A downside here is that the complex rules about when to apply RUSTFLAGS are harder for non-Cargo buildsystems to implement, and I would expect most to naively treat RUSTFLAGS like CFLAGS, applied to all invocations of rustc. For example, the Rust makefiles themselves interpret RUSTFLAGS by applying them to all invocations.

[brson]

I'd like to tackle this this week.

[brson]

I'm having second thoughts about 'RUSTFLAGS applies applies to normal builds, not buildscripts and plugins'. I feel like this is going to be non-intuitive behavior. An alternative might be - when host != target, error when RUSTFLAGS is set. Thus RUSTFLAGS works in common cases where devs are just hacking at the command line.

[cuviper]

Why even have that host!=target error? Just let people shoot their foot already. :)

On the distro side, we wouldn't be setting the environment everywhere, just within packaging scripts. This can be smart enough to set RUSTFLAGS and RUSTFLAGS_$triple as appropriate for arch-specific stuff.

On the lone wolf developer side, a broad RUSTFLAGS might be useful to set generic things like lto for all targets at once.

I would expect Cargo to use all that apply, from generic RUSTFLAGS first then specific RUSTFLAGS_$triple.

[alexcrichton]

@brson I could envision a use case of using Cargo to cross-compile for ARM boards and wanting to test out various codegen options such as the SIMD options, and that use case would at least be easier if RUSTFLAGS "just worked".

In general I feel that using RUSTFLAGS primarily means "use these flags in the output artifacts" and the fact that a bunch of other Rust code is compiled and run along the way could largely just be an implementation detail.

[brson]

An alternate proposal:

Support just RUSTFLAGS, and only for target kinds. This covers the common use cases, including debian's I think, assuming people don't need to customize build scripts and plugins. Since cargo only builds one target per invocation you can change RUSTFLAGS between invocations if you are building multiple targets. Avoids settling on the non-standard and weird RUSTFLAGS-$target variables.

In the future if it becomes important to support host kinds we add RUSTFLAGS_HOST.

[alexcrichton]

Sounds good to me

[ruuda]

There needs to be a way to specify target features that propagate to dependencies. For instance, the simd crate currently gates functionality with #[cfg(target_feature = "...")], so the target feature has to be enabled when compiling the simd crate as dependency of an executable. RUSTFLAGS in .cargo/config would solve this, but it feels wrong to me to spread build config across Cargo.toml and .cargo/config. Ideally there would be settings for the target CPU and target features in the profile.* sections of the manifest.

[alexcrichton]

@ruud-v-a the intention of RUSTFLAGS is largely for one-off testing, not for "you must set this to build this library". That usage is actually a failure mode of the feature we've been considering. Any flags required for a build to succeed should be encoded in Cargo.toml, yes.

We haven't quite figure out a story for what that means yet, though.

[ruuda]

I wrote down some thoughts on how to handle the case of required target features on the internals forum.