0.6.0: a third family for what comes out of the link, and a table shape for tools-embed

[Sunrisepeak]

Needs mcpp 2026.9.11.1, released today, which is what CI now pins.

Three families, and the prefix says which of three questions a member answers

rules-*   how is this translation unit compiled
tools-*   what does the build program need to do itself
dist-*    what comes out of the link, and in what form a user installs it

A dist-* member fits neither of the first two definitions: it compiles no translation unit and does no work while the build program runs. It consumes link outputs through a role = "artifact" action, reached with mcpp pack --format <name>. The prefix matters because the taxonomy is load-bearing — a consumer reading rules-wix would expect a compiler it does not drive and a translation unit, and there is neither.

The engine holds the dispatch and no format. dpkg's control fields, AppImage's runtime, WiX's schema and Apple's notarisation each couple a release to a release mcpp does not control. It is the argument this project already made for languages: Slang is supported without being named in the engine, and a distribution format has less claim to a name there than a language does.

Declare unconditionally, submit conditionally

generate() does both, so a consumer cannot do one without the other. The declaration is what lets the engine answer "which formats does this graph provide" on a build that asked for nothing; the submission must be gated or a plain mcpp build grows an edge it must not have. A member that declared only when asked still works for its author — they always pass their own format — and makes the set unknowable for everyone else.

The members

feature	platform	notes
dist-appimage	Linux	xim:appimagetool on the cfg(linux) axis
dist-wix	Windows	WiX CLI located, not installed — see the correction below
dist-apple	macOS	base macOS install; codesign only with an identity

dist-appimage is small because the staged tree is already an AppDir bar three files. mcpp pack --mode vendored stages bin/, lib/ and a $ORIGIN-relocatable launcher — which is what an AppImage is. So the member writes an AppRun, a .desktop entry and an icon into it and invokes one tool; it never copies or re-lays-out a directory that can be hundreds of megabytes. The three files are declared as action inputs, which is what makes a change to [package] description reach the graph.

A size floor was its first success check and was wrong on its first real fixture. A stripped hello-world stages at 14999 bytes — under the 16 KB bound — so a correct AppImage was reported as carrying no program. A size is a proxy; the question is answerable directly, so it now counts files the member did not itself write.

dist-wix names the input rather than harvesting a directory, because a bind path that resolved to nothing produced a valid, empty, 52 KB installer with no diagnostic. Its UpgradeCode is derived deterministically from package identity: WiX requires one, a random one breaks upgrades, and a hardcoded one makes every mcpp project the same product.

$(Executable), not $(var.Executable). WiX's documentation spells a -d define the second way; a working implementation green on Windows CI uses the bare form. Neither could be run here, so the one with a measurement behind it ships, and both are recorded.

dist-apple uses four chained actions rather than one, so an icon change does not force a re-copy of the whole staged tree. codesign is off by default — a member that signed unconditionally would fail every build on a machine with no identity in its keychain. iOS is the same shape plus a target row, which is a payload rather than a redesign.

tools-embed gains table()

N inputs, one header, one table, where each row carries the input's key beside its contents and the consumer iterates. file() writes one header per input and files() writes several; neither can express the shape a shader set wants. A duplicate key is refused naming both inputs, and the bytes are a numeric array rather than a raw string literal — a raw literal cannot carry arbitrary binary and its delimiter is terminable by the input, which is the defect in the CMake code this replaces.

The fixture's denominator is the manifest

tests/all-rules-compile names every member a consumer can activate, dist-appimage included. Leaving it out was the alternative and is worse: that fixture exists so every member's module is compiled on every host, and a member left out is one whose macOS and Windows compile is never attempted — exactly what the two platform-specific members are there to catch. Its payload is gated on cfg(linux), so the other two runners download nothing.

CI gains three steps, and two exist because a plan-level assertion is not a measurement

plan_for() returning applies == false on the wrong OS says the gate works and says nothing about whether the tool accepts what the member renders.

• windows-2022 installs the WiX CLI and builds a real MSI, asserting its size against the linked program's rather than that a file exists — the measured failure is a valid empty installer, and an assertion that stops at existence passes on exactly that artifact.
• macos-15 builds a real bundle, lints the plist with Apple's own parser, and runs the program through the bundle, because a bundle whose Info.plist names the wrong executable still contains a working program.
• linux runs mcpp pack --format appimage and executes the result.

A false claim is corrected rather than left to be discovered

dist/wix.cppm said WiX is "not a redistributable archive this ecosystem can vendor". Its own licence file says otherwise: the software is under the Microsoft Reciprocal License, the fee is a maintenance fee on revenue-generating use, and §2 and §3 state that binaries may be redistributed and the source remains freely distributable. The package is anonymously fetchable and immutable from NuGet's flat container (5851349 bytes, HTTP/2 200). So xim:wix is legitimate and this member should declare it with no PATH fallback, the way dist-appimage declares its own tool. The comment now records that as a gap, with the measurement behind it.

Verified locally against mcpp 2026.9.11.1

all-rules-compile      build ok  run ok
embed-consumer         build ok  run ok
embed-module-consumer  build ok  run ok
embed-table-consumer   build ok  run ok: row 0: key=Standard.vert size=20
appimage-consumer      build ok  run ok

pack --format appimage → AppimageConsumer-x86_64.AppImage → "appimage-consumer ok"
host modules compiled: mcpp.dist.appimage, mcpp.dist.apple, mcpp.dist.wix

No emoji in any of the 29 changed files; no deletions against main.