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

target.rustflags and build.rustflags conflict #14934

Closed
conradludgate opened this issue Dec 14, 2024 · 2 comments
Closed

target.rustflags and build.rustflags conflict #14934

conradludgate opened this issue Dec 14, 2024 · 2 comments
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@conradludgate
Copy link

Problem

Semi-related to #13774 (I couldn't find an exact match while searching).

Given a ~/.cargo/config.toml with the following contents:

[target.aarch64-apple-darwin]
rustflags = ["-C", "link-args=-fuse-ld=/path/to/ld"]

And a <project>/.cargo/config.toml with the following contents:

[build]
rustflags = ["--cfg", "tokio_unstable"]

When building for --target aarch64-apple-darwin, the tokio_unstable config is not set.

This makes it very awkward to have layered configuration. The linker settings I choose might be specific to my personal setup and target, whereas any config flags are specific to the project in question.

Steps

No response

Possible Solution(s)

No response

Notes

Given a ~/.cargo/config.toml with the following contents:

[build]
rustflags = ["-C", "link-args=-fuse-ld=/path/to/ld"]

And a <project>/.cargo/config.toml with the following contents:

[build]
rustflags = ["--cfg", "tokio_unstable"]

Then they are correctly merged.

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.1.1 [64-bit]
@conradludgate conradludgate added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Dec 14, 2024
@conradludgate
Copy link
Author

I filed this issue primarily because it took me an hour to debug why my rustflags was not being respected.

@weihanglo
Copy link
Member

Thanks for the detailed issue report!

While this is the current intended behaviour (target.<cfg>.rustflags has higher precedence), this is indeed surprising sometimes.

Here are some relevant discussions:

Let's close this in favour of others so we don't discuss the same thing in different places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants