You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My team builds our software for 5 different Rust targets:
aarch64-apple-darwin
x86_64-apple-darwin
x86_64-unknown-linux-gnu
wasm32-unknown-unknown
x86_64-pc-windows-msvc
When building for macOS, we typically only build aarch64-apple-darwin, but sometimes also build for Intel Macs when we're putting together a release. Similarly, on Linux, we sometimes are compiling for the host architecture, but sometimes (especially in CI) compiling for wasm.
If we don't include our extra targets in rust-toolchain.toml, we'll run into errors when running cargo with a cross-compilation target (unless we explicitly install the toolchain). If we do include the extra targets, they'll get installed on every machine and CI runner, whether it makes sense or not. (We really don't need the macOS targets when we're on a Linux CI runner trying to make sure our wasm binary compiles.)
While it's not that hard to explicitly install the toolchain where we need it, it's extra friction vs. sticking it in the targets list and having it automatically installed.
Solution you'd like
It would be nice if there were a way to keep all of our supported targets listed in rust-toolchain.toml, but defer installation of the target until cargo is invoked for that particular target.
It's the best of both worlds - we get automatic installation of the cross-compilation targets we need, but we don't end up installing them eagerly on systems where it doesn't make sense.
As a strawman, one could imagine something like the following:
[toolchain]
channel = "1.80.1"components = ["rustfmt", "clippy"]
# List all targets that we support.targets = [
"aarch64-apple-darwin",
"x86_64-apple-darwin",
"x86_64-unknown-linux-gnu",
"wasm32-unknown-unknown",
"x86_64-pc-windows-msvc",
]
# Only install the target on the host machine at the time it is actually needed.lazy-target-installation = trueprofile = "minimal"
Notes
No response
The text was updated successfully, but these errors were encountered:
AFAIK the target list is designed mostly for embedded projects that essentially require extra targets to be installed, and it should be considered the minimum requirement for compiling your project, so I personally won't recommend using that field for your use case.
As a matter of fact, this project itself is also targeting multiple platforms (actually tens of them IIRC), and please feel free to get inspired from how we're currently set things up in terms of CI/CD.
Besides, since the project has recently decided against automatic toolchain installation (#3635), I'm not sure it'll be coherent to move in the direction that you envisioned at the beginning of this thread at this moment. Sorry!
Problem you are trying to solve
My team builds our software for 5 different Rust targets:
When building for macOS, we typically only build aarch64-apple-darwin, but sometimes also build for Intel Macs when we're putting together a release. Similarly, on Linux, we sometimes are compiling for the host architecture, but sometimes (especially in CI) compiling for wasm.
If we don't include our extra targets in rust-toolchain.toml, we'll run into errors when running
cargo
with a cross-compilation target (unless we explicitly install the toolchain). If we do include the extra targets, they'll get installed on every machine and CI runner, whether it makes sense or not. (We really don't need the macOS targets when we're on a Linux CI runner trying to make sure our wasm binary compiles.)While it's not that hard to explicitly install the toolchain where we need it, it's extra friction vs. sticking it in the targets list and having it automatically installed.
Solution you'd like
It would be nice if there were a way to keep all of our supported targets listed in rust-toolchain.toml, but defer installation of the target until
cargo
is invoked for that particular target.It's the best of both worlds - we get automatic installation of the cross-compilation targets we need, but we don't end up installing them eagerly on systems where it doesn't make sense.
As a strawman, one could imagine something like the following:
Notes
No response
The text was updated successfully, but these errors were encountered: