Expand description
What this release pins: one sysroot artifact per target, by URL and by hash.
Design: spec/cross-compile/13-distribution.md section 13.2, which says every downloaded
artifact has a hash pinned in the rucc release, checked before use, with a mismatch being a hard
failure and no flag to get past it. Section 13.8 divides the work in three and the other two are
written: rucc_driver::fetch moves the bytes with a program the machine already has, and
rucc_driver::install decides whether what arrived is the right tree. This is the third, which
is the statement of what the right one is, and it is the half that makes the other two mean
anything.
§Why it is here rather than with the two halves that use it
Because it is read by something that cannot depend on the driver. The distribution manifest of
section 13.5 is generated by a build tool, the same way docs/TARGETS.md and tests/link-lines
are, and what it says about a target is what this table says plus what crate::Wall says. A
build tool that pulled in the whole driver to read three strings would be a layer violation
dressed up as convenience. It sits well here for a second reason as well: a pin is a fact about
a sysroot, which is what this crate is for, and the fetch and the install are what a driver does
with one.
§Why the table is in the binary
Because a hash that travels with the artifact is not a pin, and a hash in a file beside the compiler is a hash whoever replaces the artifact can replace too. The release is the authority for what an artifact of that release is, so the table is compiled into the release, which also means an upgrade can change a URL without anything on the machine having to be told.
It is a table rather than a computed URL for the same reason. A name built out of a version and a tuple looks tidier and quietly says that every target’s artifact is at a predictable address forever, which is a promise about somebody else’s file server. A row per target costs three strings and says only what is true.
§What is in it
Three rows, which are the three windows-gnu targets. bin/mingw-headers in tamnd/rucc-cross
installs mingw-w64 14.0.0’s headers, bin/artifact packs the tree, and the release
sysroots-2026-09-18 is where the files are. Each archive is 8.4 MiB of the same 1702 headers,
84 MiB installed, and the three differ only in the target line of the manifest inside them,
because mingw-w64 has no per architecture split and crate::Sysroot::splits_by_arch says so.
Every other target is still unpublished, which is a statement about producers rather than about
this table: --fetch of one says so by name, and the day a tree for it is published is the day a
row for it is added here. The rows that are here are the first thing --fetch has ever had
anything to move, so they are also what the fetch and the install are tested against.
Structs§
- Pinned
- One artifact: the sysroot for one target, as this release pins it.
Constants§
- PINNED
- Every artifact this release pins, in tuple order.
Functions§
- pinned_
for - The artifact this release pins for
tuple, if it pins one. - pinned_
targets - Every target this release pins an artifact for, for a message that has to say what there is.