[MSYS2] Allow default host triple to be overridden by an environment variable

[pgalbraith]

Problem you are trying to solve

MSYS2 on Windows provides multiple development environments which can share the same $HOME and therefore the same rustup configuration, but which require different Rust host ABIs. For example:

native Windows → x86_64-pc-windows-msvc
UCRT64         → x86_64-pc-windows-gnu
CLANG64        → x86_64-pc-windows-gnullvm

The appropriate host is therefore a property of the current development environment rather than of the user, machine, or project.

At the same time, a project may want to pin its Rust version without pinning its host ABI:

[toolchain]
channel = "1.97"

Ideally, the same project would then resolve that partial toolchain specification according to the active environment:

native Windows → 1.97-x86_64-pc-windows-msvc
UCRT64         → 1.97-x86_64-pc-windows-gnu
CLANG64        → 1.97-x86_64-pc-windows-gnullvm

Rustup already supports this distinction conceptually: an unqualified toolchain such as 1.97 is completed using rustup's default host. However, the default host is persisted in rustup's configuration, so environments sharing the same rustup home cannot have different defaults.

RUSTUP_TOOLCHAIN does not solve the problem because it selects the complete toolchain and overrides rust-toolchain.toml. Using it to select the ABI would therefore also override the project's choice of Rust version.

Separate RUSTUP_HOMEs can provide separate persisted default hosts, but that makes the host choice a property of separate rustup installations. For environments such as MSYS2, the host choice is naturally a property of the currently active shell environment, while the environments otherwise share the same home directory, projects, and installed tooling.

Solution you'd like

Add an environment variable, perhaps RUSTUP_DEFAULT_HOST, which overrides rustup's configured default host when resolving a toolchain specification that does not contain an explicit host.

For example:

export RUSTUP_DEFAULT_HOST=x86_64-pc-windows-gnullvm

combined with:

[toolchain]
channel = "1.97"

would resolve to:

1.97-x86_64-pc-windows-gnullvm

This would allow environments such as MSYS2 UCRT64 and CLANG64 to set their appropriate default host during environment initialization while continuing to share the same RUSTUP_HOME.

The environment variable would affect only resolution of the omitted host component. It would not select or override the channel/version as RUSTUP_TOOLCHAIN does.

Conceptually, host resolution could follow:

explicit host in toolchain specification
    ↓
RUSTUP_DEFAULT_HOST
    ↓
configured default_host_triple
    ↓
normal rustup host detection/defaulting

An explicitly host-qualified toolchain would therefore remain authoritative, while an unqualified toolchain could inherit its host ABI from the current execution environment.

Notes

No response

[rami3l]

@pgalbraith Hello, and thanks for filing this issue!

I think the problem reported here is quite reasonable and the suggested solution might even play quite well with #4947, but I remember that there had been some concerns WRT the extra complexity introduced by adding new environment variable overrides to this project.

@rust-lang/rustup do you think this would be a nice feature to have? If not, what potential alternatives could/should we suggest? 🙏

[rami3l]

@pgalbraith Also, I have an additional question since I'm not super familiar with MSYS2 to see if this is the best way forward: in other environments, we'd expect the host machine to have a single main host tuple and multiple target tuples, overridable with CARGO_BUILD_TARGET. What is preventing you from using that in your case?

[pgalbraith]

@rami3l Thanks for picking up on the topic, I hope others can weigh in because I feel I'm too new to Rust, especially, to confidently drive this home. My suggestion and PR here are my best read on the situation after only a few days with Rust :-).

If you're using MSYS2 environments on windows, you can easily land in one of three relatively independent toolchain environments depending on your env config: either standard windows powershell with msvc toolchain, msys2 bash shell with gnu toolhain, or msys2 bash shell with llvm toolchain. So the 'host' is really describing your build toolchain, it's the build toolchain that varies from env to env, not the build target. My understanding varying CARGO_BUILD_TARGET is you're not varying your build toolchain, rather just the target ABI, so this doesn't solve the problem. I hope it makes sense :-).

[rami3l]

@pgalbraith Thanks for your reply, but I think I may need to know your original issue to see the full picture.

What I was trying to say is that if you just want to compile a single project to different target platforms, then installing 3 different toolchains of different host tuples on the same machine makes little sense, as you should probably just install the 3 targets on a single toolchain of your choice (say MSVC) and compile to those targets, and that final part is absolutely overridable with CARGO_BUILD_TARGET.

Otherwise, the only possibility I can think of is that you're relying on certain parts of the host toolchain for your particular goal, not just the compiled artifacts from your project? What would that be?

[ChrisDenton]

cc @mati865, in case you have any thoughts on switching between different msys2/cygwin environments with rust.

[pgalbraith]

The smoking gun, for me, is the user guide for windows, which steers you to changing the default host, to work with MSYS2, rather than simply setting CARGO_BUILD_TARGET, which would be a much cleaner solution, if it worked.

[rami3l]

The smoking gun, for me, is the user guide for windows

@pgalbraith ... and the end of that page states exactly that you can use a different CARGO_BUILD_TARGET to support a different target tuple:

You don’t need to switch toolchains to support all windows targets though; a single toolchain supports all four x86 windows targets

... as long as you have rustup target added that tuple beforehand :)

[pgalbraith]

@rami3l Looking at this again, I agree, it's not standing up to scrutiny. My original problem has evaporated with correct target, and the best example of any remaining potential problem that I've been able to find, is in rust-libxml. For me, building this fails under msys (even with the correct target set), but I'm also not convinced this build script just isn't plain looking at the wrong env value.

I'll withdraw the PR and leave this issue to see if anyone with more rust/msys experience wants to chime in.