Using build.rustflags is awkward right now #3052
Comments
|
"-C target-cpu=native" is a single argument (i.e. there’s no shell which does argument splitting for you), so what the target binary really receives is not Alas, you cannot do such splitting either, because that would preclude people from passing over stuff (i.e. filenames) with spaces in it. |
|
I dunno, I would expect that the command is simply concatenated together and passed to the shell, as that's less work (a huge priority of cargo's) and more flexible. You can pass files with spaces in them the same way as people have done for my entire life, by escaping the space with Either way I think we can agree that passing the flag twice is wrong. |
|
@CamJN did you happen to also have Also we can and should accept configuration like: [build]
rustflags = "-C target-cpu=native"99% of the time splitting on spaces is all you want, and the list ( |
|
@alexcrichton nope, both RUSTFLAGS and CARGO_BUILD_RUSTFLAGS are unset. A repo which exhibits the behavior: https://github.com/CamJN/min |
|
Weird! In any case I'm going to tag this as an easy bug as it should be pretty easy to knock out. There's basically a point where we call |
|
If the config with the |
|
Yup, that's the same issue. |
Implemented string lookup for `build.rustflags` config key This addresses the immediate issue described in #3052 . I am, however, unsure about the current state of the deeper issues mentioned in that issue, but if needed, I can take stab at them as well. :)
|
Is this still an issue? I can see that the PR #3356 has been merged |
|
Indeed! |
This was left as a future-possibility in [RFC rust-lang#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html). Without a clear role for this field within Cargo/crates.io, there seems little reason to actively support it (e.g. rust-lang#14949, rust-lang#15027), including working through feature requests. I see the potential for having some fields with more specific roles (where to go for support, where to go for disclosing vulnerabilities, etc) but even these run into the mutable data problem of `authors`. Users can always manage metadata for their own purposes through `package.metadata`. The RFC called out clap as an example of something that uses this. Clap no longer does by default but users can opt-in through a `help_template`. For now, this notes the status in the documentation. When we have[user control over Cargo lint (rust-lang#12235) (and figure out namespacing with lints that overlap with Rust), we can give a warning on this. Based on feedback from users, we can evaluate removing this field in a future edition. We may want to consider doing similar for `badges`
This was left as a future-possibility in [RFC rust-lang#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html). Without a clear role for this field within Cargo/crates.io, there seems little reason to actively support it (e.g. rust-lang#14949, rust-lang#15027), including working through feature requests. I see the potential for having some fields with more specific roles (where to go for support, where to go for disclosing vulnerabilities, etc) but even these run into the mutable data problem of `authors`. Users can always manage metadata for their own purposes through `package.metadata`. The RFC called out clap as an example of something that uses this. Clap no longer does by default but users can opt-in through a `help_template`. For now, this notes the status in the documentation. When we have[user control over Cargo lint (rust-lang#12235) (and figure out namespacing with lints that overlap with Rust), we can give a warning on this. Based on feedback from users, we can evaluate removing this field in a future edition. We may want to consider doing similar for `badges`
### What does this PR try to resolve? This was left as a future-possibility in [RFC #3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html). Without a clear role for this field within Cargo/crates.io, there seems little reason to actively support it (e.g. #14949, #15027), including working through feature requests. I see the potential for having some fields with more specific roles (where to go for support, where to go for disclosing vulnerabilities, etc) but even these run into the mutable data problem of `authors`. Users can always manage metadata for their own purposes through `package.metadata`. The RFC called out clap as an example of something that uses this. Clap no longer does by default but users can opt-in through a `help_template`. For now, this notes the status in the documentation. When we have[user control over Cargo lint (#12235) (and figure out namespacing with lints that overlap with Rust), we can give a warning on this. Based on feedback from users, we can evaluate removing this field in a future edition. This is as discussed in a recent Cargo team meeting ### How should we test and review this PR? ### Additional information We may want to consider doing similar for `badges`
Based on #2535 and rust-lang/rust#23238 and rust-lang/rust#13841. I thought I could add
to my ~/.cargo/config file to pass that flag to my builds. But that breaks everything. Turns out I have to use
["-C", "target-cpu=native"]which is weird but it works, so w/e. However when I runcargo build --verboseI noticed that the-C target-cpu=nativeflag gets passed to rustc twice in immediate succession. ie:rustc src/main.rs --crate-name min --crate-type bin -g --out-dir /Users/camdennarzt/Developer/Rust/min/target/debug --emit=dep-info,link -L dependency=/Users/camdennarzt/Developer/Rust/min/target/debug -L dependency=/Users/camdennarzt/Developer/Rust/min/target/debug/deps -C target-cpu=native -C target-cpu=nativerustc: 1.11.0
cargo: 0.11.0 (259324c 2016-05-20)
uname -a: Darwin SECUR-T.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
The text was updated successfully, but these errors were encountered: