Repository navigation
build(release): build tools for more python-build-standalone platforms - #4248
Merged
rickeylev merged 3 commits intoOct 12, 2026
Merged
Conversation
Prebuilt tools need to run wherever rules_python runs Python, i.e. on every platform that python-build-standalone supports. Linux x86_64 runners now also cross-compile static musl binaries for armv7, i686, ppc64le and riscv64, and a Windows x86_64 runner cross-compiles for 32-bit Windows with MSVC's x86 tools. Static Linux binaries don't depend on the system's libc, so they also cover the glibc and musl variants, and arm64e Macs can run the aarch64 binary. s390x is skipped for now: Rust has no musl std for it, and a static glibc build needs a C cross toolchain. The crates now list a triple for each release platform. With crate_universe's default triples, they were incompatible with e.g. x86_64 macOS and arm64 Windows, so those jobs would only have warned. Work towards bazel-contrib#4216
The workflow and dev/platforms headers now say that s390x isn't covered and how arm64e is. The MODULE.bazel comments explain the crate triples and the toolchain ordering more precisely.
crate_universe's wasm and nixos default triples aren't needed: the crates only have to build for the platforms in dev/platforms.
rickeylev
added a commit
that referenced
this pull request
Oct 13, 2026
The release tools workflow could drift from dev/platforms unnoticed, hold a runner for six hours if a build hung, and only warn when a job asked for a platform that its ref lacks. It also didn't check that the Windows files are for the right CPU, though the i686 one is cross-compiled. A test now checks that the workflow's matrix and dev/platforms name the same platforms. Jobs time out after 30 minutes; builds take a few minutes. build.sh fails with an error if dev/platforms lacks the job's platform, since that's the caller's mistake; other build failures still only warn. Jobs still skip the build for refs without dev/platforms, like older release branches. verify.sh checks that each Windows file is a PE file for the triple's CPU, reading the machine type from the PE header because `file`'s descriptions change between versions. Also explains the "musleabihf" suffix in dev/platforms, and notes in RELEASING.md that a failed "Build tools" job doesn't block a release. Work towards #4216 (follow-up to #4248)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prebuilt tools need to run wherever rules_python runs Python, i.e. on
every platform that python-build-standalone supports.
Linux x86_64 runners now also cross-compile static musl binaries for
armv7, i686, ppc64le and riscv64, and a Windows x86_64 runner
cross-compiles for 32-bit Windows with MSVC's x86 tools. Static Linux
binaries don't depend on the system's libc, so one binary per CPU
covers both glibc and musl, and arm64e Macs run the aarch64 binary.
No job builds s390x yet: Rust has no musl std for it, and a static
glibc build needs a C cross toolchain.
The release transition now passes +crt-static for musl too, since Rust
links musl dynamically by default for some CPUs, e.g. riscv64.
crate_universe now resolves the crates' conditional deps for triples
that match the release platforms by CPU and OS, and no longer marks the
crates incompatible with other platforms, since rules_rust has no
ppc64le triple. With the default triples, the crates were incompatible
with e.g. x86_64 macOS and arm64 Windows, so those existing jobs would
only have warned.
The Linux Rust toolchain set is renamed to rust_release_linux to
shorten its labels. Its name, and the new Windows set's, must sort
after rules_rust's default sets' so that the defaults' x86_64
toolchains take precedence.
Work towards #4216