Tracking issues for the -Zmultitarget feature

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.

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

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

SGTM.

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

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.

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?

@rfcbot

-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

@weihanglo

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.

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

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.

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.

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.

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).

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.

Merge #9424 #9958 #10685

Navigation Menu

Repository navigation

Tracking issues for the `-Zmultitarget` feature #8176

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issues for the -Zmultitarget feature #8176

Description

Activity

4ad commented on Nov 24, 2020

alexcrichton commented on Nov 24, 2020

4ad commented on Nov 24, 2020

khionu commented on Jul 25, 2021

Jasper-Bekkers commented on Feb 27, 2022

edwincoronado commented on Mar 9, 2022

weihanglo commented on Jun 18, 2022

rfcbot commented on Jun 18, 2022

rfcbot commented on Jun 28, 2022

ehuss commented on Jun 28, 2022

khionu commented on Jun 28, 2022

Lokathor commented on Jun 28, 2022

ehuss commented on Jun 29, 2022

rfcbot commented on Jul 8, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issues for the `-Zmultitarget` feature #8176