-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[target.'cfg(...)'] doesn't expose all keys (like test and features) #8170
Comments
According to https://doc.rust-lang.org/cargo/reference/config.html#target:
This clearly says that However, it does seem to imply that |
Currently rustflags is not determined on a per-compilation basis, but rather an extremely coarse per- |
I discovered this while trying to enable source-based code coverage (rust-lang/rust#79121) for my test binaries. It would be convenient to be able to add "-Zinstrument-coverage" to RUSTFLAGS when running "cargo test" but not impact debug or release builds. I'd initially thought this was a small oversight, but it sounds like a fix may require some architectural changes. Is this something that could be worked with some guidance, or is it a significant enough change to require an RFC? |
I ran into this issue today. I had some code where we want to change |
I also ran into this issue today. Expected a cfg expression like |
This config does not behave as intended, as (somewhat counterintuitively) cfg in the config does not have access to all the usual values, including features or in this case test. See the tracking cargo rust-lang/cargo#8170
This config does not behave as intended, as (somewhat counterintuitively) cfg in the config does not have access to all the usual values, including features or in this case test. See the tracking cargo rust-lang/cargo#8170
For me, # Doesn't work, it's ignored
[target.'cfg(target_os = "linux")']
z-ng = { rustc-link-lib = ["z-ng"], rustc-cfg = ["zng"] }
# Works
[target.x86_64-alpine-linux-musl]
z-ng = { rustc-link-lib = ["z-ng"], rustc-cfg = ["zng"] }
|
I'm proposing to the cargo team that we close this based on a discussion in a previous cargo team meeting which is covered in the This Development-cycle in Cargo: 1.77. I have the impression there isn't a sufficiently viable way of implementing support for this. Instead, we likely should focus on things like global, mutually exclusive features. |
Problem
I am trying to override
rustflags
for my test binaries. But I don't want to do this for the normal, non-test binaries.In theory, you can use the
[target.'cfg(...)']
syntax to influence rustflags on a very granular basis. However, it appears thatcfg()
is missing a few keys when compiling test binaries, notablytest
andfeature
.FWIW,
--test
and--cfg 'feature="build-mode-standalone"'
is getting passed intorustc
when building the test binaries. So something in Cargo knows about them. It appears that these values aren't getting plumbed through tocfg()
evaluation.Possible Solution(s)
I think
cfg()
should have access totest
,feature
, and perhaps other conditional keys when building test binaries.Output of
cargo version
:cargo 1.43.0 (3532cf738 2020-03-17)
The text was updated successfully, but these errors were encountered: