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

Tracking issues for the -Zmultitarget feature #8176

Closed
alexcrichton opened this issue Apr 28, 2020 · 14 comments · Fixed by #10766
Closed

Tracking issues for the -Zmultitarget feature #8176

alexcrichton opened this issue Apr 28, 2020 · 14 comments · Fixed by #10766
Labels
A-cross-compiling C-tracking-issue disposition-merge finished-final-comment-period T-cargo to-announce
Projects

Comments

@alexcrichton
Copy link
Member

alexcrichton commented Apr 28, 2020

This is intended to be a tracking issue for -Zmultitarget being implemented in #8167. This feature allows passing the --target flag multiple times to Cargo to build code simultaneously for multiple targets. This was originally requested in #8156 and #3913.

Currently the semantics of -Zmultitarget is that it simply allows passing --target multiple times (2 or more) to Cargo. Cargo recognizes this as doing what it was already doing, only now for multiple targets instead of just a single target. Internally Cargo's unit graph should still have all the edges drawn correctly and whatnot.

@alexcrichton alexcrichton added C-bug C-tracking-issue and removed C-bug labels Apr 28, 2020
@ehuss ehuss added the A-cross-compiling label Apr 29, 2020
This was referenced Apr 29, 2020
@ehuss ehuss added this to Unstable, baking in Roadmap Apr 30, 2020
@4ad
Copy link

4ad commented Nov 24, 2020

How is this supposed to interact with the (currently single) target specification in config.toml?

@alexcrichton
Copy link
Member Author

alexcrichton commented Nov 24, 2020

I think we'd probably want to implement support for build.target = ["array", "of", "targets"]

@4ad
Copy link

4ad commented Nov 24, 2020

SGTM.

@khionu
Copy link
Member

khionu commented Jul 25, 2021

Just saw that the referenced PR is closed. Are there any pending steps before closing this issue?

@Jasper-Bekkers
Copy link

Jasper-Bekkers commented Feb 27, 2022

Just saw that the referenced PR is closed. Are there any pending steps before closing this issue?

I'm also curious about potential next steps on this issue, as we're trying to streamline the Android development experience.

@edwincoronado
Copy link

edwincoronado commented Mar 9, 2022

I have a config.toml file that looks like this:

[unstable]
multitarget = true

[build]
target = ["nightly", "nightly-i686-unknown-linux-gnu"]

but getting an error "build.target" expected a string, but found a array, using the cli --target argument is really not an option for me since I'm using workspaces for a large project.

Does anybody know a workaround?

@weihanglo
Copy link
Contributor

weihanglo commented Jun 18, 2022

-Zmultitarget exists on nightly for years (#8167, merged in April 2020). It has already been in the wild for a long time, and is the main code path of cargo compilation since then. The support of multitarget in .cargo/config.toml has landed (March 2022 #10473) with only minimal additions.

It may be the time to push it to stable. #10766 tries to stabilize it. Need some inputs from others.

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Jun 18, 2022

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period disposition-merge labels Jun 18, 2022
@rfcbot rfcbot added the final-comment-period label Jun 28, 2022
@rfcbot
Copy link
Collaborator

rfcbot commented Jun 28, 2022

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period label Jun 28, 2022
@ehuss
Copy link
Contributor

ehuss commented Jun 28, 2022

One note I wanted to point out is that cargo doc and cargo install do not support multiple targets. I do not think that is a blocker for stabilizing, but is something that may want to be considered in the future if those are things someone wants.

It is also not supported by the unstable artifact-dependencies and per-package-target feature (in the sense that they only allow selecting a single target). Also not a blocker, and also can be added at any time in the future. Just trying to note that this has a ripple effect across other features.

@khionu
Copy link
Member

khionu commented Jun 28, 2022

One note I wanted to point out is that cargo doc and cargo install do not support multiple targets. I do not think that is a blocker for stabilizing, but is something that may want to be considered in the future if those are things someone wants.

It is also not supported by the unstable artifact-dependencies and per-package-target feature (in the sense that they only allow selecting a single target). Also not a blocker, and also can be added at any time in the future. Just trying to note that this has a ripple effect across other features.

Rustdoc marks features as being only active for certain targets, and cargo install is meant for installing on the local machine, so neither cargo doc or cargo install really make any sense. The one exception I can think of is for WASM applications, you would want cargo install to build for WASM, but that seems a bit of a clunky use of cargo install anyways.

@Lokathor
Copy link

Lokathor commented Jun 28, 2022

cargo install might be wanted to build for any platform with an emulator, but yes you probably don't need multitarget in that case, a project probably only supports that one platform.

@ehuss
Copy link
Contributor

ehuss commented Jun 29, 2022

Yea, cargo install is probably not applicable.

However, for cargo doc I was thinking it would generate:

target/x86_64-apple-darwin/doc/…
target/aarch64-apple-darwin/doc/…

That is, equivalent to running cargo doc --target x86_64-apple-darwin && cargo doc --target aarch64-apple-darwin. I can't think of a good use case for that, though.

It would be interesting if rustdoc could union multiple target cfgs within the same documentation (without needing to do #[cfg(doc)] shenanigans like the standard library does).

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 8, 2022

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rfcbot rfcbot added to-announce and removed final-comment-period labels Jul 8, 2022
@ehuss ehuss moved this from Unstable, baking to Done in Roadmap Jul 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cross-compiling C-tracking-issue disposition-merge finished-final-comment-period T-cargo to-announce
Projects
Roadmap
  
Done
Development

Successfully merging a pull request may close this issue.

9 participants