Enabling target features in .cargo/config does not work for cfg statements in Cargo.toml

[newpavlov]

Originally reported in RustCrypto/stream-ciphers#11

Create a project with following files. Cargo.toml:

[target.'cfg(target_feature="aes")'.dependencies]
either = "*"

.cargo/config:

[target.'cfg(any(windows, unix))']
rustflags = ["-Ctarget-feature=+aes"]

src/main.rs:

#[cfg(target_feature="aes")]
fn main() { println!("aes enabled"); }

#[cfg(not(target_feature="aes"))]
fn main() { println!("aes disabled"); }

Running cargo run outputs "aes disabled" as expected, but either crate does not get downloaded, i.e. cfg statement in Cargo.toml does not work as expected. And as a consequence adding #[cfg(target_feature="aes")] extern crate either; to main.rs results in a compilation error. Meanwhile RUSTFLAGS="-C target-feature=+aes" cargo run works as expected without any issues.

[ehuss]

This is an interesting problem. There's a circular requirement where to determine the cfg flags it needs to know the cfg flags. Cargo currently starts with an empty set (see TargetInfo) and runs rustc to determine the starting cfg set. To handle this situation, it would need to repeatedly call rustc to build up the cfg rules until it stabilizes. My instinct is that is not practical, or at least would be complex or slow. However, I can't think of any other way around it (other than, as you mention, using the RUSTFLAGS env var, and enabling that using some external script or tool).

[posix4e]

Any updates?

[d-e-s-o]

The same issue seems to affect cfg(debug_assertions). Debugging this kind of stuff can be a huge time sink. At the very least we should be printing a warning, in my opinion.

[daladim]

I've just run into this problem when trying to conditionally build tokio-console (that itself declares a condtional dependency based on rustflags).

I have crafted another minimal reproducer that you can try at https://github.com/daladim/cargo-target-cfg-evaluation-order-bug

[Systemcluster]

This should be strongly noted in the documentation.

It notes Do not try to match on debug_assertions or Cargo features like feature="foo", but from @ehuss's comment "Cargo currently starts with an empty set" I understand that cfg directives in .cargo/config don't work at all.

I spent around a day trying to set -Ctarget-feature and -Ctarget-cpu based on cfg targets in .cargo/config, and it took me quite a bit to find this issue.

Running cargo run outputs "aes disabled" as expected

I don't think this is expected at all. With a config like

[target.'cfg(any(windows, unix))']
rustflags = ["-Ctarget-feature=+aes"]

I would expect the aes feature to be enabled for all windows and unix targets, and as currently documented this is very non-intuitive. In fact, the documentation even lists it as an example, which is very misleading in light of this issue and #10439:

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "my-arm-wrapper"
rustflags = ["…", "…"]

[ehuss]

Adding this limitation to the documentation sounds good to me.

I understand that cfg directives in .cargo/config don't work at all.

cfg directives should work. This issue is just about having a dependency between .cargo/config.toml and dependencies in Cargo.toml. An expression like cfg(any(windows, unix)) will set the given rustflags on those platforms, and will be able to see that from #[cfg] attributes. It's just that you can't key off it in a target dependencies table.

If you are not able to get cfg expressions to work (and that aren't involved with Cargo.toml), feel free to open a new issue with a reproduction.

[Systemcluster]

If you are not able to get cfg expressions to work (and that aren't involved with Cargo.toml), feel free to open a new issue with a reproduction.

I might be misreading the issue, but I think #10439 was describing the behavior without involvement of Cargo.toml, and got closed in favor of this one.

Thanks to your answer I tested it a bit further and it appears that rustflags in a cfg target (additionally to not affecting Cargo.toml) only don't affect the CARGO_CFG_TARGET_FEATURE environment variable available to build.rs, while still affecting the actual compilation. This threw me off the track a bit, as I was using that variable in a build.rs to try to figure out the rustflags interactions.

Is there another way to query which target-features are enabled for a build, without querying each one with conditional compilation individually?

[ehuss]

Yea, cfg settings affected by target.'…'.rustflags in a config won't show up in build scripts, either.

Unfortunately, I can't think of a workaround to detect those settings from a build script. You could perhaps run rustc --print=cfg along with CARGO_ENCODED_RUSTFLAGS as arguments, and parse the output?