-
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
Add a build.cargoflags
configuration key
#8127
Comments
It looks like there's some precedent for a different approach to globally enabling cargo Z flags in how mtime_on_use is configured. Doing this for all unstable flags would (I think) be as simple as modifying the snippet linked above to something like this:
I put together #8393 to see how that'd work, and I think it'd satisfy what you're trying to do @phil-opp -- lmk if you agree or if you would still prefer to see something like a cargoflags config entry. |
Yes, I think this would solve my issue. I didn't know about the |
Glad to hear it -- no problem! I didn't know about unstable either until I saw mtime-on-use doing it, and I figured... why not? |
Describe the problem you are trying to solve
The cargo command line API has some
-Z
flags that allow to opt-in to unstable functionality. Examples are-Z build-std
, which recompiles the sysroot for custom targets, or-Z features=build_dep
, which fixes the long-standing problem tracked by #5730.The problem with these flags is that they need to be explicitly passed to every invocation of cargo, which has many downsides:
-Z build-std
).cargo
invocations in CI scripts etc.rust-analyzer
also need to be adjusted to pass the required flag.As a result of these downsides, many people refrain from using unstable command line features for their (nightly) projects. This means that the features are less tested by the community before they are stabilized at some point.
Describe the solution you'd like
To solve these problems, I think there should be a way to enable cargo command line flags from a configuration file. One possibility for this could be to introduce a new
build.cargoflags
key in.cargo/config
files, similar to the existingbuild.rustflags
andbuild.rustdocsflags
keys. This would be a relatively simple change that solves all the mentioned problems.Notes
Given that it's already possible to enable unstable features of the
rustc
command line API throughbuild.rustflags
, there is already a precedent for enabling unstable command line features from.cargo/config
files.The text was updated successfully, but these errors were encountered: