rust-lang
Don't create .msi installer for gnullvm hosts
WIX toolset works only on Windows hosts, but gnullvm doesn't have host toolchain yet. To get out of this loop, we will create a single release without MSI installer.
Split out from: https://github.com/rust-lang/rust/pull/140772
r? @kobzol
rustbot has assigned @kobzol. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
WIX toolset works only on Windows hosts.
If that's the case, then disabling it for non-Windows-hosts seems fine I think?
Well, it disables creation of .msi installers that are officially provided by Rust. So I'm not sure whether it should be a more conscious decision (via the config) or the implication of using non-Windows host is fine.
I think there should be a config, it sounds surprising that you suddenly get different results with the same config.
If the host was not Windows-based before, the build would fail (good luck running WIX or .exe files otherwise). Now it would be silently skipped. I don't think that we need a config for this, but the build should fail instead. So if target is Windows, but the host isn't, bootstrap should bail out.
That would mean https://github.com/rust-lang/rust/pull/140772 is a no-go in the current form. I'll check how painful it would be to bootstrap from other Windows host soon.
Hmm, I don't see why that should be the case. Do the -gnullvm targets require MSI installers? If not, then we can just modify the check here from is_windows() to is_windows_but_not_gnu_llvm (or just is_msvc). If yes, then we cannot build them from a non-Windows host anyway.
x.py dist for any Windows host does run (or at least tries to) WIX.
I had hoped msi installers could be missing for a single release (after the initial bootstrap these triples can host themselves in the dedicated job). So if condition like that is fine I'd go for it.
Sorry, I'm not sure if I understand that :sweat_smile: If the -gnullvm targets should contain the MSI installer in their dist archives, we will need to build these target on Windows hosts, right? Because we can't produce these installers from Linux hosts (AFAIK?).
In the end they should, to be consistent with other hosts at https://forge.rust-lang.org/infra/other-installation-methods.html The question is whether gnullvm hosts could temporally skip .msi installer for their first release? If the answer is no, or it requires a proposal, I'll drop this change and try with Windows jobs.
The question is whether gnullvm hosts could temporally skip .msi installer for their first release?
I'm fine with that, but what I didn't understand is the "for their first release" part. What changes after the first release? How will we be able to create the MSI installers from Linux hosts?
Sorry for not giving the full context here, I thought I had included it here in the previous comments, but it must have been a different issue/PR/channel.
Let me fix that. My idea is to create the initial release with host tools for 86_64 and AArch64 windows-gnullvm triples using Linux host. It's the easiest way to achieve that (the possibility to run the containers locally helps a lot), but that means MSI installers are not achievable. Once the host toolchain for these targets is present in the beta channel, Linux jobs for cross-compiling it would be replaced by native Windows jobs. Windows-gnullvm from that point forward would host themselves, so creating MSI installers becomes possible.
Oh, I see, ok, thanks for the explanation. In that case I'm fine with that, although I would appreciate if the check was only scoped to the gnullvm targets, rather than windows as a whole.
The job mingw-check-tidy failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)
##[endgroup]
[TIMING] core::build_steps::tool::ToolBuild { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu, tool: "tidy", path: "src/tools/tidy", mode: ToolBootstrap, source_type: InTree, extra_features: [], allow_features: "", cargo_args: [], artifact_kind: Binary } -- 9.560
[TIMING] core::build_steps::tool::Tidy { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu } -- 0.000
fmt check
Diff in /checkout/src/bootstrap/src/core/build_steps/dist.rs:1681:
cmd.run(builder);
}
- // FIXME(mati865): `gnullvm` here is temporary, remove it once it can host itself
- if target.is_windows() && !target.contains("gnullvm") {
+ // FIXME(mati865): `gnullvm` here is temporary, remove it once it can host itself
+ if target.is_windows() && !target.contains("gnullvm") {
let exe = tmp.join("exe");
let _ = fs::remove_dir_all(&exe);
fmt: checked 6052 files
Build completed unsuccessfully in 0:00:44
local time: Mon Jun 9 21:51:50 UTC 2025
network time: Mon, 09 Jun 2025 21:51:50 GMT
@Kobzol sorry for the delay, I've been too busy recently. I think this should be fine to go now, once a new Rust version with gnullvm hosts is up, I'll revert this PR.
