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

Make CARGO_BUILD_TARGET accept multiple target triples #14820

Open
madsmtm opened this issue Nov 14, 2024 · 3 comments
Open

Make CARGO_BUILD_TARGET accept multiple target triples #14820

madsmtm opened this issue Nov 14, 2024 · 3 comments
Labels
A-configuration Area: cargo config files and env vars A-cross-compiling Area: using --target flag for other platforms C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.

Comments

@madsmtm
Copy link
Contributor

madsmtm commented Nov 14, 2024

Problem

It is really nice that Cargo supports compiling for multiple platform target triples (not to be confused with the artifacts that Cargo produces). However, it is inconvenient that this capability does not extend to CARGO_BUILD_TARGET.

Proposed Solution

Make CARGO_BUILD_TARGET take multiple values, potentially comma-separated, such that CARGO_BUILD_TARGET=aarch64-apple-darwin,aarch64-apple-ios cargo build would work the same as cargo build --target aarch64-apple-darwin --target aarch64-apple-ios.

Perhaps we could even extend --target to allow comma-separated target triples too?

As a bit of prior art, x.py in rust-lang/rust supports comma-separated target triples.

Notes

This wouldn't work with custom target triple paths that contain commas. How common are these? And would it be okay to break, since custom target json specs are unstable anyhow?

This was also discussed in #10473, but nothing further was done about this yet (from my understanding?)

@madsmtm madsmtm added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Nov 14, 2024
@epage epage added A-configuration Area: cargo config files and env vars A-cross-compiling Area: using --target flag for other platforms S-needs-team-input Status: Needs input from team on whether/how to proceed. and removed S-triage Status: This issue is waiting on initial triage. labels Nov 14, 2024
@epage
Copy link
Contributor

epage commented Nov 14, 2024

To clarify, this is talking specifically about CARGO_BUILD_TARGET and not build.target which accepts multiple values as of #10473.

(sometimes people refer to env or config to refer to both)

@weihanglo
Copy link
Member

To myself I am still hoping -Zadvanced-env instead of a special case.

@ehuss
Copy link
Contributor

ehuss commented Nov 19, 2024

We talked about this a little in our team meeting, but didn't come to a conclusion. We noted that there we already support space-separated lists in environment variables, but because build.target is defined using a custom one/many deserializer, it doesn't support space-separation like it would if it used the StringList or UnmergedStringList type. One option is to just switch it to use our standard type and remove the custom impl.

The other option as weihang noted above is to support a more general-purpose array encoding for environment variables. For example, one problem with space-separation (or comma separation) is that custom spec .json files include paths which could include spaces, which would break here if we didn't use some encoding like TOML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars A-cross-compiling Area: using --target flag for other platforms C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.
Projects
None yet
Development

No branches or pull requests

4 participants