autocfg
autocfg copied to clipboard
cuviper
rust-flags specified in cargo configs are ignored by autocfg.
When invoking rustc autocfg adds rustflags from the RUSTFLAGS environment variable. This makes things like setting --sysroot work.
The problem is flags can also be specified in the cargo configurations: https://doc.rust-lang.org/cargo/reference/config.html
These do not seem to be picked up properly by autocfg, so some crates (indexmap in my case) cannot detect features properly if you set important flags like --sysroot in ~/.cargo/config or .cargo/config or any of the other paths used.
It's going to get really hairy if we try to duplicate cargo's logic for finding all applicable config files, as well as parsing the flags from [build], [target.$triple], and even [target.cfg(...)]! Note that every config entry can also be set as CARGO_FOO_BAR environment variables.
Maybe we should make a Cargo feature request to set its resolved RUSTFLAGS for build scripts?
Hairy indeed! It might be possible to do something with the cargo rustc command. I just tried the following:
$ cat .cargo/config [target.thumbv7neon-unknown-linux-gnueabihf] rustflags = ["--sysroot=/path/to/target/sysroot"]
$ cargo rustc --target thumbv7neon-unknown-linux-gnueabihf -- --print sysroot /path/to/target/sysroot
Sadly cargo can't handle there being no Cargo.toml and it sets a bunch of flags. It is possible to set:
[lib] path="-"
in Cargo.toml but there is no way of actually passing stdin to rustc.
Using cargo rustc is a clever idea, and it might work to point it at -p autocfg to avoid creating a dummy crate. However, from a build script this will probably get stuck waiting for the directory lock, since cargo is already running.
Going back to a dummy crate, it needs to be a subdirectory of the original crate to inherit the same .cargo/config possibilities, but build scripts aren't supposed to write anything but OUT_DIR. That might be a totally different location via CARGO_TARGET_DIR. Plus, I think the workspace interaction would be a problem.
You're right. I my particular case I'm using the global cargo config and then it works. But not for crate specific configs.
It also doesn't seem to be possible to make cargo stop linking so it's going to be a bit more fragile.
See also https://github.com/rust-lang/cargo/issues/4423
TL;DR: cargo doesn’t make a good distinction between host rustflags and target rustflags, which I imagine would complicate matters here further.
