-
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
Support -Zmultitarget
in cargo config
#10473
Conversation
For backward compatible reason, `build.target` starts accepting both array of string and a single string.
r? @ehuss (rust-highfive has picked a reviewer for you, use r? to override) |
thanks for getting to this so fast @weihanglo ! I have one quick question, it looks like I would still have to do [unstable]
multitarget = true basically do the same so that I only have to do |
@edwincoronado that's correct. You might need on nightly channel at this moment to turn on
Ref: https://doc.rust-lang.org/1.59.0/cargo/reference/unstable.html#unstable-features |
maybe use word "targets" instead of "target" ? |
@edgeone89 I've considered the solution and it's indeed more intuitive. However, when we want to maintain the backwards compatibility we need to preserve |
@weihanglo ok, thanks. |
Every target listed in Note that when using |
any update on this? |
All review comments are resolved. I was trying to avoid extra allocation, but it turns that the relevant code is not in the hot path during compilations. Your suggestion indeed reduces the code complexity. Thank you! |
The relevant is not in the hot path for a cargo build, so it acceptable to allocation String in order to reduce code coomplexity
ba13a1e
to
3c8ba9a
Compare
src/cargo/util/config/mod.rs
Outdated
let values = match &self.inner.val { | ||
BuildTargetConfigInner::One(s) => vec![map(s)], | ||
BuildTargetConfigInner::Many(v) => { | ||
if v.len() > 1 && !config.cli_unstable().multitarget { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this skip the length check, just to prevent target = ["foo"]
, which would be new syntax?
if v.len() > 1 && !config.cli_unstable().multitarget { | |
if !config.cli_unstable().multitarget { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, missed that one. Thanks!
Should be fixed now and I tweak the error message a bit.
Thanks! @bors r+ |
📌 Commit c18275b has been approved by |
☀️ Test successful - checks-actions |
Update cargo 13 commits in 109bfbd055325ef87a6e7f63d67da7e838f8300b..1ef1e0a12723ce9548d7da2b63119de9002bead8 2022-03-17 21:43:09 +0000 to 2022-03-31 00:17:18 +0000 - Support `-Zmultitarget` in cargo config (rust-lang/cargo#10473) - doc: Fix document url for libcurl format (rust-lang/cargo#10515) - Fix wrong info in "Environment variables" docs (rust-lang/cargo#10513) - Use the correct flag in --locked --offline error message (rust-lang/cargo#10512) - Don't treat host/target duplicates as duplicates (rust-lang/cargo#10466) - Unstable --keep-going flag (rust-lang/cargo#10383) - Part 1 of RFC2906 - Packages can inherit fields from their root workspace (rust-lang/cargo#10497) - Remove unused profile support for -Zpanic-abort-tests (rust-lang/cargo#10495) - HTTP registry implementation (rust-lang/cargo#10470) - Add a notice about review capacity. (rust-lang/cargo#10501) - Add tests for ignoring symlinks (rust-lang/cargo#10047) - Update doc string for deps_of/compute_deps. (rust-lang/cargo#10494) - Consistently use crate::display_error on errors during drain (rust-lang/cargo#10394)
What does this PR try to resolve?
Support
-Zmultitarget
in cargo config. This patch also takes care of backward compatibility, so basically it means thatbuild.target
accepts input from both string and array.#8176 (comment)
How should we test and review this PR?
Several new tests in
multitarget
.I didn't add tests for all compile modes, since doing that would produce too many duplications. If anyone thinks it necessary to avoid potential regression please tell me.
Unresolved questions
CARGO_BUILD_TARGET
environment variable? Should it remain accepting a single target value only and hopeadvanced-env
save us?