0.19.0: one tool-source resolver for every member, on-request payloads, and a toolchain description library #41

Activity

1. speak-agent

   closed this as completedin #43on Oct 1, 2026
2. speak-agent commented on Oct 1, 2026

   

   speak-agent

   on Oct 1, 2026

   MemberAuthor

   More actions

   Released as 0.19.0

   One resolver answers, for every member, where the tool it runs comes from: mcpp.plugins.tool, in one order — the build program's choice, the member's legacy variable, the engine's override, then the declared payload, asked for there when it is declared provision = "on-request".

   A choice never asks for the payload, which is what makes "the build program names its own tool" mean "the payload is not downloaded". Every answer is recorded with mcpp::decision, so a build reports the source and mcpp why tool <name> answers from the same record; describe_missing is the one refusal text, listing every way to name the tool.

   Thirteen members use it: deps-vcpkg, deps-cmake, deps-archive, rules-cuda, rules-hip, rules-sycl, rules-ascendc, rules-slang, rules-spirv, rules-qt, dist-apk, dist-appimage, dist-wix. Five entries are now installed on request: xim:vcpkg, xim:cmake (twice), xim:appimagetool, xim:bundletool.

   mcpp.plugins.toolchain (feature plugins-toolchain) builds the statement a root build program makes in a toolchain phase: layout, prefixed, managed, from_env_script, newest_under, env, the with_* refinements, configure(fn) / use(d).

   What this release measured in its own CI, beyond the 28 plugin-logic cases and the consumer fixtures:

   • xim:vcpkg no longer appears in the macOS or Windows rules job logs, where main provisions xim:vcpkg@>=2026.7.27. That saving is also what exposed a defect in the test kit: it left the real build's MCPP_XPKG_* in the environment, including pending for an on-request payload nothing had asked for, so eight vcpkg cases planned nothing wherever the payload was absent — 19 of 27 on macOS and Windows, 27 of 27 where it was installed. Measured both ways on one binary: 19 → 27.
   • rules-sycl's migration conflated the payload root with the program, so -L pointed at the compiler's path and the SYCL consumer failed with unable to find library -lsycl. Fixed, and every migrated member audited for the same swap.
   • A stated program path now follows the host's own executable-suffix rule: on Windows command -v cmake answers a path with no .exe, which the resolver had refused.

   Engine floor: mcpp 2026.10.1.3 (protocol 15, mcpp-community/mcpp#755).

   Released

   • Merged as 7f5f0ed after the PR run came back green on all four jobs against the released mcpp 2026.10.1.3 (Linux consumers, macOS rules, Windows rules, Windows deps).
   • Tagged v0.19.0, released on GitHub, and mirrored to GitCode (mcpp-res/mcpp-plugins@0.19.0) with the local gtc; the mirrored asset was downloaded back and cmp-verified byte-identical to the GitHub archive, sha256 2dd13d81cffd77babdb1070d24659348d2f699c634981f66e3e97206389c5c7e.
   • Registered in mcpp.plugins 0.19.0 mcpplibs/mcpp-index#505 (56990ac), whose workspace matrix rebuilds every member against this version; the index artifact is published, so clients resolve it.
   • fix(qt): track files referenced by QRC resources #42 was reviewed and merged first, so its qrc_files fix is in this release rather than displaced by it. Measured before merging: 22 of 23 cases without the fix, with both resource assertions failing, and 23 of 23 with it.

   Verified against the released artefacts in xlings subos eco-1001, through the CN mirror, in a private MCPP_HOME: PASS s755_plugins -- a named cmake is used and the payload is not asked for, alongside the two engine scenarios (3 passed, 0 failed).

   docs/tool-sources.md is the reference for both audiences; its chapter 3 gives each way of naming a tool as a complete build.mcpp, every one of them compiled against this release before being written down.