We need configurably additive rustflags!

tools and infrastructure cargo
1

There are four mutually exclusive sources of extra flags. They are checked in order, with the first one being used:

  1. CARGO_ENCODED_RUSTFLAGS environment variable.
  2. RUSTFLAGS environment variable.
  3. All matching target..rustflags and target..rustflags config entries joined together.
  4. build.rustflags config value

https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags

This mutual exclusivity is quite annoying, and could be even problematic.

Suppose you have something like this in your global configuration:

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/usr/bin/mold"]

[target.x86_64-unknown-linux-musl]
rustflags = ["-Z", "gcc-ld=lld"]

Now suppose you need to enable a cfg, let's say tokio_unstable in one or more of your crates.

  • RUSTFLAGS does enable the cfg, but your global linker settings are ignored!
  • Using crate-local/workspace-local build.rustflags, as often suggested, doesn't work at all.
  • You need to add all your global per-target rustflags in your crate-local/workspace-local config with cfg appended.

Now, suppose you want to set -Z threads=n globally... well, it's not really global anymore, unless you use a higher-priority rustflags-setting method which will override your other settings!

Am I missing anything?

9 Likes
2

Alternatively, useful rustflags should be adopted "natively" by Cargo, as either cargo/config or Cargo.toml options.

For example, there's already linker setting, so you don't need rustflags for it:

[target.x86_64-unknown-linux-musl]
linker = "lld"
3

Sure. But that's not a generic solution.

Right now, it's not rare to find suggestions of e.g. enabling a cfg via adding the flags in the build section of .cargo/config. Some even seem to think that checking that file in is enough, and things should just work for others, being totally oblivious to the mutual exclusivity problem.

I just find it weird that there is no way to reliably locally append rustflags without having to check global config (and the environment) first, and that global config is not a base that can be appended to. Unless using build.rs is considered "the right solution" here!

1 Like
4

linker = "lld" will make rustc directly invoke lld doesn't it? That only works on msvc windows, wasm32-unknown-unknown, wasm32-wasi and baremetal systems. On unix you have to use a linker driver like gcc or clang. You can then tell this linker driver to use lld as actual linker using -fuse-ld=lld.

5

Cargo on Unix could be smarter about this and use a linker driver if necessary, instead of exposing inconsistent platform-specific behavior.

For example, you can set debug = true in Cargo.toml, and not care if that's -g or /Zi, or whether it needs dSYM paths or pdb formats or whatnot. You specify what you want, and in that case Rust/Cargo is smart enough to abstract the underlying details from you. You don't even need to know if Cargo is doing it, or is that a rustc option, or some gcc thing. It just works. IMHO linkers should work like that. I say linker = "mold", and Cargo makes it work.

1 Like
6

It would be good to have more of the flags exposed through native cargo configs. But there'll always be flags that have been added to rustc and haven't yet been exposed by cargo that I really think some way to separate the "user's flags" from the "project's flags" and combine them is necessary. I set some unstable flags like -Zrandomize-layout globally that I doubt will be exposed by cargo anytime soon.

4 Likes
7

Maybe there's a need for EXTRA_RUSTFLAGS that adds to the others?
(EXTRA_CFLAGS is a common Makefile idiom.)

4 Likes