v0.5.2

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release. Nothing about the packaged runtime changed, the binaries here are the same programs built from the same pin as v0.5.0 and v0.5.1. What changed is that Bazel now runs on Windows and resolves a C++ toolchain there, which is the boundary between a machine that can start the build and a machine that can do it. That is M6 work, native hosting.

Pinned to upstream modular/v25.7.0-29742-g9aba62be84, commit 9aba62be844d73b574a4283a1a8ce760f9843134.

Download mojo-windows-runtime-0.5.2-x86_64.zip, unpack it, run bin\hello.exe. Nothing to install first. Windows 10 version 1809 or later, x64.

What changed

Bazelisk can now fetch a Bazel that runs on Windows. .bazelversion names buildbuddy-io/5.0.382, a fork BuildBuddy publishes with four assets, and none of them is Windows, so bazelisk asked for one, got a 404 and stopped before it had started. The Windows wrapper maps that name to the stock Bazel it is actually a fork of. That is #243.

The Bazel on Windows friction list has been checked against a real machine rather than assumed. #34 collected the problems that get described as inevitable, and most of them do not survive contact: case insensitivity is not a problem at this pin, clang-cl version parsing cannot apply because nothing here runs clang-cl, and long path support is the one item on the list that is real and not optional. What actually stopped the build was three things that were not on the list at all, and docs/building.md now has the whole account. That is #34.

One of those three was ours and it took a while to find. Bazel's rc parser treats a backslash as an escape character and drops it, so the SystemRoot line the Windows wrapper generates arrived at the build as C:WINDOWS, which is not a broken path but a drive relative one. What that broke was Bazel's own Windows SDK autoconfiguration, which sat waiting on a shell dialog on a desktop nobody was looking at until it timed out ten minutes later. Doubling the backslash is the only form the parser leaves alone. That is #248.

The cc toolchain has a Windows execution platform. Every toolchain() was registered with exec_compatible_with naming Linux or macOS, so with Bazel running on Windows nothing resolved and analysis stopped with no matching toolchain for the C++ toolchain type, which is a confusing thing to be told on a machine with a compiler on it. This adds a clang that runs on Windows, the tool definitions that go with it, and a registration that names Windows as a machine and not only as a target. The part that took the work was the selects that are keyed on the target platform and mean the execution platform, which had been right only because host and target always agreed. That is #247.

Test results

Every suite is unchanged, which is the point of a patch release.

Windows tier 0 is 232 passing, one target that does not build and five skipped. Windows tier 1 is 75 passing and three skipped. The Win64 ABI conformance test passes. Linux tier 0 is 236 passing with two that do not build, Linux tier 1 is 76 passing and two skipped. The Windows build failure is #230, an AMDGPU codegen test rather than anything Windows specific.

The manual acceptance checklist was run against this archive and every result is in docs/acceptance.md. Four items pass, one is not applicable without a compiler on Windows, one was not re-run because nothing it covers changed, and two still need a person sitting at a console.

What still does not work

There is still no mojo.exe. A resolving toolchain is not a compiler, and analysis on a Windows host is not a build.

Two things are in the way and both were found while finishing the toolchain work. The pip lock file has three environments and none of them is Windows, so the mypy aspect the build turns on for every target cannot resolve its own dependencies, which is #252. Behind that, the three toolchain driver scripts are bare Python files and Windows has no shebang, so the first compile action will fail to launch until they get something that Windows can actually start, which is #253.

A stack overflow still prints nothing, which is #239, and it still arrives as an access violation rather than as STATUS_STACK_OVERFLOW, which is #238. Every other fault prints a proper symbolised trace.

Files

The overlay archives are built by CI from the tag and carry a provenance attestation. The Windows archives are cross compiled from Linux by hand and carry checksums only, because CI cannot build them and attesting them there would sign a claim that is false. docs/releasing.md explains that at more length.