mcpp toolchain list filters vocabulary rows through host_can_serve, which answers can this host serve the target from a payload. It then presents that answer as can this host build for the target. Those are different questions, and one row separates them today.
Measured
Host: Linux x86_64, 2026-08-25, mcpp 2026.8.25.1.
x86_64-windows-musl does not appear in mcpp toolchain list. The same host builds it:
$ mcpp build --target x86_64-windows-musl
kernel-abi openkal (openkal-windows@0.1.5, graph)
c-abi musl (openkal-musl@0.3.5, graph)
c++-abi libc++ (openkal-llvm-runtime@0.1.3, graph)
Finished dev [unoptimized + debuginfo] in 2.95s
$ file target/.../winmusl.exe
PE32+ executable (console) x86-64, for MS Windows, 14 sections
A real PE, from a Linux host, for a target the tool's own answer to "what can I build for?" leaves out.
Why the filter is right and the use is wrong
host_can_serve returns false for this row on a non-Windows host, and correctly so — there is no prebuilt Windows/musl system to install. The target's own table row says what happens instead:
The C library still comes from the dependency graph. host_can_serve says no for this row on a non-Windows host — correctly, for the prebuilt system — and that refusal is diagnosed early and RELEASED once the graph is known.
prepare.cppm already implements that release (unservedTargetDiagnosis). lifecycle.cppm's listing loop has no equivalent, so a row that a build would accept is dropped from the list.
Not every absent row is this
x86_64-windows-msvc and aarch64-macos are also absent on a Linux host and are absent correctly: MSVC and the macOS SDK are host-only, and no dependency graph substitutes for them. A fix must keep those out.
What it needs
A predicate for "the graph can supply this target's system on this host", which does not exist yet — host_can_serve is about payloads and the table has no column for it. Listing a target that cannot in fact be built here would be worse than the present omission, so this wants a real predicate rather than a heuristic over pin or is_musl().
Found during the #503 review. Deliberately not fixed there: #503 fixes four defects that are all a predicate applied to a question narrower than itself, and adding a guessed predicate to that PR would be the same mistake.
mcpp toolchain listfilters vocabulary rows throughhost_can_serve, which answers can this host serve the target from a payload. It then presents that answer as can this host build for the target. Those are different questions, and one row separates them today.Measured
Host: Linux x86_64, 2026-08-25, mcpp 2026.8.25.1.
x86_64-windows-musldoes not appear inmcpp toolchain list. The same host builds it:A real PE, from a Linux host, for a target the tool's own answer to "what can I build for?" leaves out.
Why the filter is right and the use is wrong
host_can_servereturns false for this row on a non-Windows host, and correctly so — there is no prebuilt Windows/musl system to install. The target's own table row says what happens instead:prepare.cppmalready implements that release (unservedTargetDiagnosis).lifecycle.cppm's listing loop has no equivalent, so a row that a build would accept is dropped from the list.Not every absent row is this
x86_64-windows-msvcandaarch64-macosare also absent on a Linux host and are absent correctly: MSVC and the macOS SDK are host-only, and no dependency graph substitutes for them. A fix must keep those out.What it needs
A predicate for "the graph can supply this target's system on this host", which does not exist yet —
host_can_serveis about payloads and the table has no column for it. Listing a target that cannot in fact be built here would be worse than the present omission, so this wants a real predicate rather than a heuristic overpinoris_musl().Found during the #503 review. Deliberately not fixed there: #503 fixes four defects that are all a predicate applied to a question narrower than itself, and adding a guessed predicate to that PR would be the same mistake.