Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rust-flags specified in cargo configs are ignored by autocfg. #15

Closed
janderholm opened this issue Nov 11, 2019 · 7 comments
Closed

rust-flags specified in cargo configs are ignored by autocfg. #15

janderholm opened this issue Nov 11, 2019 · 7 comments

Comments

@janderholm
Copy link

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.

@cuviper
Copy link
Owner

cuviper commented Nov 11, 2019

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?

@janderholm
Copy link
Author

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.

@cuviper
Copy link
Owner

cuviper commented Nov 11, 2019

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.

@cuviper
Copy link
Owner

cuviper commented Nov 11, 2019

See also rust-lang/cargo#7501

@janderholm
Copy link
Author

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.

janderholm added a commit to janderholm/meta-rust that referenced this issue Nov 12, 2019
audiocfg does not have support for using anything but the RUSTFLAGS
environment variable:

cuviper/autocfg#15
@matklad
Copy link
Collaborator

matklad commented Nov 13, 2019

See also rust-lang/cargo#4423

TL;DR: cargo doesn’t make a good distinction between host rustflags and target rustflags, which I imagine would complicate matters here further.

@cuviper
Copy link
Owner

cuviper commented Mar 25, 2024

Since Rust/Cargo 1.55 (rust-lang/cargo#9601) and autocfg 1.1.0 (#39), we should be getting the correct flags from CARGO_ENCODED_RUSTFLAGS, whether host or target, environment or config, etc.

@cuviper cuviper closed this as completed Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants