feat(huxerui): 0.3.0, and a CI pin that follows the engine - #385
Merged
Conversation
Form A entry for the HuxerUI SDK plus its workspace member. The
descriptor is finished and `mcpp xpkg parse` accepts it -- "form A, no
mcpp segment". What is NOT finished is the thing the index actually
promises, that a consumer can build the package, so this is committed
as the record of where it stops rather than opened as a PR.
WHAT THE DESCRIPTOR DECIDES
`xpm.linux.deps` carries the 36-entry GTK closure by hand. Upstream
declares it on the target axis, which is the form mcpp recommends and
which a descriptor structurally cannot carry: three platform blocks, and
a cfg selector is not a platform. Consumer edges therefore come from
this file, at PLATFORM level -- a per-version `deps` is inert, the same
finding compat.eui-neo records. Omitting them would let a consumer
resolve, build, and die at link on the GTK sonames.
`licenses` and `repo` deliberately disagree with `mcpp emit xpkg`, which
emits Apache-2.0 and Sunrisepeak/HuxerUI. The v0.3.0 tree's LICENSE is
MIT verbatim and the canonical repo is HuxerUI/HuxerUI; upstream's
mcpp.toml is wrong on both and is being corrected separately. No `mcpp`
segment: pasting emit's table form makes the parser read this as an
inline Form B and refuse it for missing `sources`.
WHY IT CANNOT LAND
1. VERSION FLOOR. v0.3.0's mcpp/huxerui-build-rules calls
`mcpp::package_name()` and `mcpp::package_namespace()`, added in mcpp
#587 (2026-09-08) and first released in v2026.9.7.1. validate.yml
pins MCPP_VERSION 2026.9.6.3, one release short, so the host module
fails to compile: `'package_name' is not a member of 'mcpp'`.
2. ACTION BUFFER OVERFLOW, and this one survives a newer mcpp. On
2026.9.10.2 the build gets past (1) and dies in build.mcpp:
build.mcpp declared an action whose arguments did not fit
payload: {"id":"hrc:builtin", … "overflow":true}
`mcpp::action` uses fixed buffers -- `inputs_[8192]` -- and the
hrc:builtin action enumerates all 44 files under resources/. Measured:
as a dependency those paths total 8131 bytes, plus ~106 for the hrc
binary, against a 8192-byte cap. In-tree the same list is 1531 bytes,
and the same source builds clean in 21.45s.
So the trigger is the 149-character dependency unpack prefix, not the
file count, and it overflows by roughly 45 bytes. That is worse than a
clean failure: whether a consumer builds depends on how deep their
project sits on disk. mcpp's own error names the fix -- declare the
resources DIRECTORY as one input instead of enumerating it -- and that
belongs in huxerui-build-rules, not here.
No CN mirror yet: mirroring a version that cannot be consumed would
publish a promise this index cannot keep.
The descriptor and its member landed in the previous commit as a record
of two blockers. One turned out not to be a blocker at all and the other
is fixed here, so this completes the addition.
THE OVERFLOW WAS THE MEASUREMENT, NOT THE PACKAGE
The `hrc:builtin` action was reported as overflowing mcpp's fixed
`inputs_[8192]`. It does -- at a 149-character unpack prefix. Measured
across three path lengths, the same source and the same engine:
149 chars (deep local checkout) 8131 B + ~106 B overflows
109 chars (ordinary path) 6371 B builds
in-tree, relative 1531 B builds, 21.45s
So the trigger is the prefix, not the file count, and it clears at any
ordinary checkout depth. It is still a real trap -- roughly 45 bytes of
margin, decided by how deep a consumer's project sits -- and mcpp's own
error names the fix (declare the resources DIRECTORY as one input rather
than enumerating 44 files). That belongs in huxerui-build-rules and is
filed there; working around it in this index would be the wrong place.
THE PIN, WHICH IS A REAL BLOCKER AND MOVES HERE
`mcpp/huxerui-build-rules` calls `mcpp::package_name()` and
`mcpp::package_namespace()` -- mcpp#587, first released in v2026.9.7.1 --
so under the old 2026.9.6.3 pin the host module does not compile:
rules.cppm:274:61: error: 'package_name' is not a member of 'mcpp'
#361 established the pattern for exactly this, down to the reasoning: a
package whose build program uses a current engine API is not a defect, a
CI that cannot run current engines is. MCPP_VERSION moves to 2026.9.10.2.
`index.toml` min_mcpp does NOT move, and that is verified rather than
assumed: `mcpp xpkg parse` accepts this descriptor under 2026.8.27.2 (the
floor), 2026.9.6.3 and 2026.9.10.2 alike. The floor is about descriptor
grammar; only BUILDING this package needs the newer engine, so a client
on the floor keeps resolving the whole index.
VERIFIED
mcpp test -p huxerui-module → test result ok. 1 passed
same, on 2026.9.6.3 → 'package_name' is not a member
assertion inverted → FAILED. 0 passed; 1 failed
The last one matters: the test opens no window, and Rect/Color alone
would compile even if libhuxerui had never been built. FlatLightThemeSpec
and FlatDarkThemeSpec are out-of-line definitions inside the library, so
reaching them is what proves the link -- and inverting the check proves
the assertion is live.
CN mirror mcpp-res/huxerui@0.3.0 is up and byte-identical to GLOBAL
(http 200, 9946045 bytes, sha 8b326d95…). All five lint checks pass on
the new descriptor, and the three repo-wide ones pass across pkgs/*/*.lua.
The pin move pays the cold-cache cost the workflow comment warns about,
so any other descriptor waiting on a newer engine should ride along.
…osure
Two corrections the PR's own CI earned.
NO xim:wix ON WINDOWS
`mcpp emit xpkg` emits `deps = { "xim:wix@5.0.2" }` because upstream
declares wix on the HOST axis, which is the axis a descriptor can carry.
Emitted is not the same as needed: wix.exe builds an MSI, nothing else in
the SDK touches it, upstream's rule tolerates its absence by construction
inline ... wix() {
const std::string root = mcpp::xpkg_dir("xim", "wix");
if (root.empty()) return {};
and upstream's manifest says an application that wants an installer
"declares this line too". The dependency belongs to that application, not
to everyone who imports huxerui on Windows.
It was also breaking both Windows shards outright -- `xim:wix`'s install
hook fails on a clean runner:
E_INTERNAL: [wix] failed: install hook failed:
tar -xf "...\xim-x-wix\5.0.2\.nupkg\wix.nupkg" -C "...\tool"
; wix installed but registered none of its declared programs
taking every Windows consumer down with it for a tool almost none would
run. That hook is a separate xim-pkgindex defect; this descriptor should
not have been asking for wix either way.
FOUR DEPS, NOT THIRTY-SIX
The list existed to guarantee the payloads are INSTALLED, and installation
is transitive: each xim package declares its own deps, and `xlings remove
pango` is refused, naming `xim:gtk4` as the holder, so the reverse edges
are live. Discovery is a different mechanism -- `mcpp::xpkg_dir` answers
from the BUILDING package's own manifest, and upstream's mcpp.toml already
declares the whole closure on its target axis.
So the descriptor needs only what upstream's cmake and build.mcpp ask
pkg-config for directly. Verified by clearing the member's sandbox and
rebuilding with the short list: `test result ok. 1 passed`. Naming the
other 32 restates pins this index does not own.
Note the asymmetry with the xim-pkgindex entry, which is NOT a mistake:
there the deps drive both installation and, through the aggregated
sysroot pkgconfig view, discovery. Here upstream's manifest owns
discovery. Same four names, different reasons.
The pin move and the mysql-connector-cpp regression it surfaces are a
separate matter, still under investigation.
… scanner regression The pin moved to 2026.9.10.2 on the reasoning that #361 took the current release. CI disagreed: `mysql-connector-cpp` failed on linux default, linux llvm AND macOS, deterministically, while every other member passed. It is not that package's fault, and not a dependency problem. mcpp's scanner errors on an ordinary block comment in libmysqlclient's `sql-common/client_plugin.cc`. Reduced to four lines: /* module (exe) */ int main() { return 0; } error: scanner errors: src/main.cpp:2: '(exe) ... A line inside a block comment is read as a module declaration when the comment's opener sits on its own line -- the same text on one line (`/* module (exe) */`) scans fine, and `module x` without the parenthesis scans fine either way. So a comment that merely uses the English word "module" before a parenthesis breaks the scan. Bisected across releases with that file: 2026.8.27.2 OK 2026.9.7.1 OK 2026.9.6.3 OK 2026.9.10.2 scanner errors The regression therefore lands AFTER 2026.9.7.1 -- which is precisely the release that first carries `mcpp::package_name()`, the API huxerui's build program needs. The floor and the last good version are the same release, so this takes the floor. Verified at 2026.9.7.1, both members that mattered: mcpp test -p huxerui-module test result ok. 1 passed mcpp test -p mysql-connector-cpp test result ok. 1 passed Reported upstream. Move to the tip once the scanner is fixed -- and per the batching note above, that move should carry any other descriptor waiting on a newer engine.
…t a dep The plan still described the first attempt: pin at 2026.9.10.2 and `xim:wix` kept as emitted. CI rejected both, and the reasons are worth keeping rather than quietly overwriting. - The pin is 2026.9.7.1, the FLOOR, because a scanner regression lands in 2026.9.9.1 (still present in 2026.9.11.1) and breaks mysql-connector-cpp. Four-line repro and the bisect are recorded; mcpp-community/mcpp#606. - windows carries no `xim:wix`: emitted is not needed, and its install hook fails on a clean runner. xim-pkgindex#808. - A section on what CI caught that local verification structurally could not, including the one failure still open (mysql-connector-cpp on the llvm leg) and where huxerui itself stands per leg. This also re-triggers CI, which now resolves `xim:wix` from an index snapshot that carries the #808 fix.
…osis The plan credited xim-pkgindex#808 with fixing the Windows failure. It did not: keeping the host's tar and adding a PowerShell fallback only moved the error from 'exec failed ... tar -xf' to 'registered none of its declared programs'. What settled it was already in the first log -- curl ran fine in the same hook moments before tar did not, so the payload was downloaded and sha-verified before execution ever reached the extractor. One is a declared dependency; the other was the host's. xim-pkgindex#809 declares xim:7zip and extracts with it. Recording the wrong turn rather than only the answer: the fallback in #808 is exactly the shape that let this hide in the first place. Also re-triggers CI, which now resolves xim:wix from a snapshot carrying the #809 fix.
…ndex's cache key Two separate reasons, and the second one invalidates a conclusion this branch reached twice. THE SCANNER REGRESSION IS FIXED 2026.9.7.1 was chosen as the FLOOR because 2026.9.9.1 introduced a scanner regression — mcpp read inside a block comment and choked on libmysqlclient's `module (exe or dll) …`, breaking mysql-connector-cpp on linux and macOS. Reduced to four lines, reported as mcpp-community/mcpp#606, and fixed in 2026.9.11.2. Verified all three: four-line scanner repro builds clean mcpp test -p huxerui-module test result ok. 1 passed mcpp test -p mysql-connector-cpp test result ok. 1 passed So the pin no longer has to sit four releases behind to stay green. THE PIN IS THE ONLY WAY TO REFRESH THE INDEX `xim:wix` was fixed twice upstream — xim-pkgindex#808, then #809 — and after each merge the windows leg here failed identically. Both times that was read as "the fix did not work". Neither had ever been loaded. `actions/cache` holds `~/.mcpp/registry`, which contains `data/xim-pkgindex` — the resolved xim index — and its `restore-keys` prefix stops at MCPP_VERSION. While that line does not move, every run restores the same index snapshot no matter what landed upstream. The tell was in the log: `7zip`, which #809 declares, appeared ZERO times in a run supposedly testing #809. Two guesses along the way were wrong and are recorded in the plan so they are not repeated: that the release tarball bundles a frozen index (a pristine extraction has no `xim-pkgindex` at all — it is populated at run time), and that a merge therefore propagates by itself. Moving this line evicts that cache. It is the only reason the windows leg can now see the fixed recipe, and that makes this pin move load-bearing twice over. `index.toml` min_mcpp still does not move: the floor is descriptor GRAMMAR, and the descriptor parses under 2026.8.27.2, 2026.9.6.3, 2026.9.7.1 and 2026.9.11.2 alike.
…ndency sets
The member declared no `standard`, so it defaulted to c++23 -- and mcpp
applies the ROOT's standard to the whole module graph, which meant
huxerui's own sources compiled at c++23. Upstream's mcpp.toml says not to:
standard = "c++20"
# The SDK ABI baseline. Do not raise it: mcpp applies the root standard
# to the whole module graph, so this is imposed on every consumer too.
`import std;` still works -- huxerui is `language = "c++20", import_std =
true`, and the member's test passes at c++20 (`test result ok. 1 passed`).
THIS IS NOT EXPECTED TO FIX WINDOWS, and saying so up front is the point.
The windows leg fails compiling huxerui's
`src/runtime/runtime_pointer_interaction.cpp`:
xutility:320: error: static assertion failed: unexpected size
in instantiation of 'std::_Find_vectorized<
const huxerui::detail::NodeExtensionHandle, ...>'
`NodeExtensionHandle` is 24 bytes (two 64-bit integers and a pointer),
trivially copyable, with a defaulted `operator==`. MSVC STL 14.51 therefore
treats it as memcmp-comparable and dispatches `std::find` to
`_Find_vectorized`, which handles 1/2/4/8-byte elements and static_asserts
on anything else. That dispatch is not gated on the language mode, so the
standard this commit sets does not reach it: it is a clang 20.1.7 against
MSVC STL 14.51 incompatibility in a header, reached through upstream's
source, and nothing in this index can express a fix for it.
Committed because it is correct on its own terms -- a consumer should not
silently raise the ABI baseline a dependency pins -- not because it is the
windows fix.
…g cannot compile
macOS is pinned (`macos-15`) and linux is not; windows was on the rolling
label and it rolled onto the Visual Studio 18 image, MSVC STL 14.51.
mcpp builds windows with clang targeting x86_64-pc-windows-msvc, so every
package here compiles against an STL written for a different front end.
Most survive it. `huxerui.huxerui` did not:
xutility:320: error: static assertion failed: unexpected size
in instantiation of 'std::_Find_vectorized<
const huxerui::detail::NodeExtensionHandle, ...>'
MSVC STL's vectorized `std::find` is guarded by a trait deciding whether
the element type can be compared bitwise. `NodeExtensionHandle` is 24
bytes, no padding, trivially copyable, `operator==` defaulted — the guard
admits it under clang, and the helper it dispatches to implements 1/2/4/8
byte elements and static_asserts on the rest. Guard and implementation
disagree about what "vectorizable" means; only clang is there to notice.
NOT this index's bug and not the package's, and the evidence is the pin
itself: the same source and the same clang compile on the 2022 image.
Upstream HuxerUI's own mcpp CI is green for exactly that reason — it
already pins `windows-2022`. Filed as mcpp-community/mcpp#609 so the pin
can be lifted when the combination works again.
THE NARROWNESS IS THE ARGUMENT, not a reason to shrug: 13 of the 14
members on the failing shard compiled fine. A rolling label therefore
changes WHICH packages trip over this from image to image, and delivers
the failure attributed to whichever descriptor changed that week. Pinning
turns a moving target into a dated, documented decision.
…ot in the build
Section 4 already argues this descriptor should not declare `xim:wix` --
wix builds an MSI, and a consumer that merely imports huxerui has no use
for it. That is right but incomplete: it treats the declaration as
misplaced when the mechanism it belongs to simply did not exist yet.
mcpp 2026.9.11.1 opened the `--format` value set. `mcpp pack` owns the
mechanism and the universal formats; every other format lives in a package
that declares `mcpp::provides_pack_format("<name>")` in its build program,
unconditionally, and submits its action only when asked. Under that,
`xim:wix` stops being a top-level `[xlings.workspace]` entry provisioned
for every build of every consumer, and becomes a dependency of the feature
that provides `msi` -- reached only by someone actually packing one.
The timeline is the whole explanation:
HuxerUI v0.3.0 released 2026-09-10 17:36 UTC
mcpp 2026.9.11.1 released, --format 2026-09-10 20:34 UTC
`provides_pack_format` appears zero times in v0.3.0's build.mcpp and
rules.cppm. Not a road not taken -- a road that did not exist, by under
three hours.
Recorded rather than acted on: the v0.3.0 tag is immutable and upstream is
out of scope here. What the descriptor CAN do is behave as though the move
had already happened, which is what not declaring wix does -- so a future
0.3.1 needs no change on this side.
Also notes that the two Windows problems are independent: with wix gone
from the build entirely, runtime_pointer_interaction.cpp still does not
compile against MSVC STL 14.51.
This was referenced Sep 11, 2026
Sunrisepeak
added a commit
to openxlings/xim-pkgindex
that referenced
this pull request
Sep 11, 2026
…819) The windows branch added in #818 shipped a payload and declared nothing about where it is. This adds `exports.runtime.libdirs = {"bin"}` to the windows xpm block and removes the `subos.env` PATH prepend from config(). WHY THE FIRST ATTEMPT WAS THE WRONG LAYER. My comment in #818 claimed `exports.runtime.libdirs` is read only by xlings's elfpatch and therefore has nothing to say about a PE. That is false: mcpp reads the same field to COPY a dependency's *.dll beside the executable it builds (`src/build/plan.cppm`, `runtimeDeployFiles`), and its own comment names this exact case -- "only a Windows prebuilt-DLL package (or a test that ships a .dll) populates it". The chain is resolver.cpp:167 -> installer.cpp:2486 -> the runtime binding mcpp reads. `bin` and not `lib`: bin/ holds vulkan-1.dll, lib/ holds the import library the linker reads. PATH was also too wide even where it worked -- process-wide, so it would put our loader in front of the system's for every child of that shell. MEASURED, BOTH HALVES. The PATH declaration installs cleanly under a full xlings (this repo's windows-test: `done`, `[PASS] new shim`, subos "default" present) and fails inside mcpp's project sandbox with `E_INTERNAL: config hook failed` (mcpplibs/mcpp-index#391, windows leg; every other leg green, loader downloaded and installed before the hook runs). Two environments, one descriptor, opposite results. The asymmetry behind that is filed as mcpp-community/mcpp#614 -- mcpp invokes xlings with `env -u XLINGS_PROJECT_DIR` on POSIX and sets it to the EMPTY STRING on Windows, and absent and present-but-empty are not the same answer to "which scope is this". This change does not depend on that being fixed. RECORDED HONESTLY: WHY THIS PACKAGE EXISTS AT ALL. The windows payload (#818) was not motivated by a user report. It was motivated by a runner image choice made in mcpplibs/mcpp-index#385, where the Windows leg was pinned to `windows-2022` to dodge an MSVC STL 14.51 bug (mcpp-community/mcpp#609, microsoft/STL#6294). That image is the one without the loader. Measured on three images (mcpp-index#387 probe): windows-2022 vulkan-1.dll absent MSVC 14.29/14.44 huxerui PASS vulkan FAIL 0xC0000135 windows-2025 vulkan-1.dll PRESENT MSVC +14.51 huxerui FAIL (STL) vulkan PASS windows-latest same as windows-2025 Neither image satisfies both, which is what four rounds of mcpp-index#388 failed to escape before it was closed. Shipping the loader takes the image out of the question instead -- and the underlying claim stands on its own: vulkan-1.dll is not an OS component, it arrives with a GPU driver or as LunarG's redistributable, so a driverless machine has no loader and anything linking vulkan-1.lib dies before main. The `subos` import goes with the call; nothing else used it. Linux is untouched. Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com>
Sunrisepeak
added a commit
that referenced
this pull request
Sep 11, 2026
Every reason to distrust the diff used to escalate to the whole workspace. On a PR that is the wrong trade twice over: it buries the change under ~22 shards of unrelated work, and it puts the PR's own legs behind an hour of queue, so the thing under review is the last thing to report. Touching this file was enough to trigger it, which is the case that keeps biting: a one-line CI edit cannot be reviewed against a fast signal. Measured three times today -- #390, #391 and #392 each ran a full matrix to validate a change whose blast radius was one job. `full` now answers only where "check everything" IS the request: the weekly cron and a manual `workflow_dispatch`. On a PR or a push, the same reasons call `widen` instead, which records them, prints them, and writes them to the run summary so a reviewer sees WITHOUT opening a job that this run deliberately tested less -- and that the sweep is one manual dispatch away. Degraded, with their reasons kept: .github/workflows/validate.yml, tests/*.sh mcpp.toml non-member change unclassified path push with no predecessor / predecessor not in history NOT weakened: descriptor and member changes select their members exactly as before. The only thing that changed is what happens when the diff cannot be classified. One consequence handled. `widen` does not exit, so the push-with-no- predecessor path has to leave a usable range behind. `HEAD` alone would diff root-to-HEAD, name every file and select every member -- a full run by another name, which is what this change exists to stop. It leaves the range EMPTY instead: nothing selected, the reason already said, the summary carrying it to a human. Rare either way, since merges here are squashes and `event.before` is present on every normal push. The weekly Sunday 06:00 sweep is deliberately kept. It is the only thing that would have caught the windows vulkan regression before a user did -- main's leg was pinned to `windows-2022` in #385 and the vulkan members were never re-tested there until a full run happened to fire today. Removing the automatic full run on PRs and keeping the periodic net is the same shape openxlings/xim-pkgindex#815 just added on the other side. Verified: the rendered fragment on `pull_request` with a validate.yml edit plus an unclassified path selects only the member its descriptor change names, and the same input under `workflow_dispatch` still goes full. Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com>
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.
Adds the HuxerUI SDK as a Form A package, and moves
MCPP_VERSIONto the release its build program needs.Shape
Category (b) — a library developed on mcpp. Upstream carries its own
mcpp.tomland abuild.mcpp, so the descriptor declares metadata and a download address only.No
mcppsegment, deliberately: pasting emit's table form makes the parser read this as an inline Form B and refuse it (synthesised manifest missing sources). Omitting it lets the default<verdir>/*/mcpp.tomllookup findHuxerUI-0.3.0/mcpp.toml—imgui.luacarries the same note.mcpp xpkg parsereportsform A — no mcpp segment, under 2026.8.27.2 (the floor), 2026.9.6.3 and 2026.9.7.1 alike.Naming follows mcpp#278 (INV-NAME):
namespace = "huxerui"and the fully-qualifiedname = "huxerui.huxerui".Deps: four, and what they are for
The list guarantees the payloads are installed, and installation is transitive — each xim package declares its own deps (
xlings remove pangois refused, namingxim:gtk4as the holder). Discovery is a different mechanism:mcpp::xpkg_diranswers from the building package's own manifest, and upstream'smcpp.tomlalready declares the full 36-entry closure on its target axis. An earlier revision restated all 36 here; that duplicated pins this index does not own. Verified by clearing the member's sandbox and rebuilding with the short list.No
xim:wix.emit xpkgemits it because upstream declares wix on the host axis, and the host axis is the one a descriptor can carry — but emitted is not needed. wix builds an MSI, upstream's rule tolerates its absence by construction (if (root.empty()) return {};), and upstream's manifest says an application wanting an installer "declares this line too". It was also breaking both Windows shards outright:xim:wix's install hook fails on a clean runner (tar -xf … wix.nupkg→ "wix installed but registered none of its declared programs"), taking every Windows consumer down for a tool almost none would run. That hook is a separate xim-pkgindex defect.licensesandrepodeliberately disagree with emit (Apache-2.0,Sunrisepeak/HuxerUI): the v0.3.0 tree's LICENSE is MIT verbatim and the canonical repo isHuxerUI/HuxerUI. Upstream's manifest is wrong on both and is being corrected separately; the descriptor is hand-maintained and carries no AUTO-GENERATED banner, so re-emitting will not silently reintroduce them.The pin moves to 2026.9.7.1 — the floor, not the tip
huxerui's build program calls
mcpp::package_name()/package_namespace()(mcpp#587, first released v2026.9.7.1), so under the old 2026.9.6.3 pin the host module does not compile at all:This PR first moved to the current release, 2026.9.10.2, following #361. CI rejected that, and was right to:
mysql-connector-cppfailed on linux default, linux llvm and macOS, deterministically, while every other member passed.It is not that package's fault. mcpp's scanner errors on an ordinary block comment in libmysqlclient's
sql-common/client_plugin.cc. Reduced to four lines:A line inside a block comment is read as a module declaration when the comment's opener sits on its own line — the same text on one line (
/* module (exe) */) scans fine, andmodule xwithout the parenthesis scans fine either way. A comment that merely uses the English word "module" before a parenthesis breaks the scan.Bisected with that file:
So the regression is introduced in 2026.9.9.1, i.e. after 2026.9.7.1 — which is exactly the release that first carries
package_name(). The floor and the last good version are the same release, so this takes the floor. Reported upstream; move to the tip once the scanner is fixed, and per the workflow's batching note that move should carry any other descriptor waiting on a newer engine.index.tomlmin_mcppdoes not move, verified rather than assumed — the descriptor parses under the floor and both candidate pins. The floor is about descriptor grammar; only building this package needs the newer engine.Verification
The inverted-assertion check matters: the test opens no window, and
Rect/Colorare header-attached entities the module re-exports which would compile even if libhuxerui had never been built.FlatLightThemeSpec()/FlatDarkThemeSpec()are out-of-line definitions inside the library, so reaching them is what proves the link.Earlier CI on this branch also confirmed the package cold:
huxerui-module 317s okon linux.CN mirror
mcpp-res/huxerui@0.3.0, byte-identical to GLOBAL (http 200, 9946045 bytes, sha8b326d95…). CI'smirror-cn-reachablepasses.Lint
All five checks pass on the new descriptor; the three repo-wide ones pass across
pkgs/*/*.lua.Design doc:
.agents/docs/2026-09-11-add-huxerui-plan.md.Final state, and what merging carries onto
mainhuxerui-module passes on all four legs — the first run where it does:
Windows took three independent fixes, and all three had to be in place at once: a wix recipe that does not depend on the host's tar (xim-pkgindex#809), an index cache that actually carried it (the
MCPP_VERSIONmove — see §11 of the plan), and an MSVC STL that clang can compile (windows-2022).mainStating this plainly so nobody has to reconstruct it from a red dashboard.
workspace (windows default 0/5)vulkanSTATUS_DLL_NOT_FOUND(0xC0000135) at run time —vulkan-1.dllis absent from thewindows-2022imageworkspace (windows default 1/5)eui-neo-vulkan,vulkan-hpp-moduleworkspace (linux llvm 3/9)mysql-connector-cppinstall() result=nil, no scanner error; the gcc leg passes and so does a local run at 2026.9.11.2The Vulkan three are the cost of the windows pin, not a defect in those packages: they compile fine and fail at load. The Vulkan loader is not a Windows component — it arrives with a GPU driver or the Vulkan SDK — so whether a runner has it is a property of the image.
windows-2025-vs2026has it;windows-2022does not.compat.vulkan-runtimeis shape G in this index precisely because a driver cannot be vendored.So the windows pin is a trade, not a win: it moved one failure (huxerui, a compile error) and created three (Vulkan, load errors). It is merged in that state deliberately — the huxerui failure blocked the package this PR exists to add, and the Vulkan failures are understood, narrow, and independently fixable. A follow-up will try
windows-2025(VS2025 / MSVC 14.4x), which may clear both: old enough to avoid 14.51's_Find_vectorized, new enough to carry the loader.Filed for the toolchain half: mcpp-community/mcpp#609.