probe(do-not-merge): capture the Windows exit-127 at compat:ffmpeg#123
Closed
Sunrisepeak wants to merge 12 commits into
Closed
probe(do-not-merge): capture the Windows exit-127 at compat:ffmpeg#123Sunrisepeak wants to merge 12 commits into
Sunrisepeak wants to merge 12 commits into
Conversation
…106) mcpp 0.0.106 restores the canonical identity form: `namespace` carries the hierarchy, `name` is a single atomic segment. 0.0.105 briefly required the opposite (name spelled as the fully-qualified `<namespace>.<name>`), which was an encoding constraint rather than a design rule — it existed only because mcpp re-derived the wire name instead of using the literal it had already read. namespace = "compat", name = "compat.zlib" -> name = "zlib" 45 descriptors migrated; the 3 namespace-less public module packages (imgui/ffmpeg/opencv) are unchanged — a bare name IS their full identity. Three short names now repeat across namespaces: `imgui`, `ffmpeg` and `lua` (compat's versus the default namespace's, and compat's `lua` versus mcpplibs.capi's). That is legal — identity is the PAIR, and only the pair has to be unique. It needs xlings >= 0.4.69 (openxlings/xlings#381), which keys the index by (namespace, name); 0.0.106 bundles it. Verified against a local path index: bare `imgui` resolves to `mcpplibs:imgui` and `[dependencies.compat] imgui` resolves to `compat:imgui`, each installing to its own store dir. check_package_name.lua is inverted to match: `name` must be atomic, hierarchy belongs in `namespace`, and the legacy fully-qualified spelling stays accepted (the prefix is stripped before judging) so nothing published before this is invalidated. No filename lint — the filename is not part of identity. min_mcpp/latest_mcpp move to 0.0.106 in lock-step with the CI pin. This one is NOT optional: a client older than 0.0.106 re-derives `<ns>.<short>`, misses the short-name key, and reports a bare E_NOT_FOUND with nothing pointing at the cause. Verified locally: all 48 descriptors pass the inverted lint; identity pairs are unique; no `name` still carries a dot; the three counterexamples (non-atomic short name, dotted name without a namespace, legacy FQN) each behave as specified.
CI caught a real conflict the short-name migration introduced:
build_index failed: duplicate package identity 'compat:ffmpeg'
`imgui`, `ffmpeg` and `opencv` declared `namespace = ""`, meaning "inherit the
index's default namespace". 11 workspace members register this repo as
`[indices] compat = { path = ... }`, so under those members the repo default IS
`compat` — and the namespace-less descriptors became `compat:ffmpeg` /
`compat:imgui`, colliding head-on with the freshly shortened `compat.ffmpeg`
and `compat.imgui`.
The migration exposed it, but the fragility is older and independent of it: a
namespace-less descriptor's identity depends on the NAME THE CONSUMER HAPPENS
TO REGISTER THE INDEX UNDER. The same repo mounted as `compat` and as `default`
gives those three packages two different identities. That is exactly what
SPEC-001 exists to remove — identity should be what the descriptor declares.
So rather than reverting the two colliding descriptors to the legacy spelling
(which would have unblocked CI while leaving the trap armed), declare the
namespace outright:
namespace = "", name = "imgui" -> namespace = "mcpplibs"
Identity is now context-free. Verified by simulating all three registration
styles (repo default = mcpplibs / compat / default): zero duplicate identities
in every case, where before `compat` produced two.
Consumers are unaffected: a bare `imgui` still resolves via the default-namespace
search path, and `[dependencies.compat] imgui` still resolves to compat's.
Checked against the released mcpp 0.0.106 with the index mounted as `compat` —
builds clean, no duplicate-identity error.
48/48 descriptors still pass the lua lint and `mcpp xpkg parse`.
…gration
Shortening every `package.name` (SPEC-001) also changed how a descriptor must
ADDRESS another package: `pkginfo.install_dir("compat:xcb-proto")`, not the old
`compat:compat.xcb-proto`. Two install hooks kept the old spelling, and neither
failed where the mistake was:
* compat.xcb could not find xcb-proto's XML, so c_client.py never ran and the
install aborted with a bare `[xcb] failed`. libxcb.so was never built, and
CI reported it three levels downstream as
`libX11.so: undefined reference to xcb_connection_has_error` in gui-stack,
imgui-module and imgui-window.
* compat.x11 only checked the lookup for nil, never `os.isdir`, so it carried
on with a directory that does not exist and generated its keysym tables from
no headers at all — silently, with a successful build.
Both now try the SPEC-001 spelling first and keep the pre-SPEC-001 ones as
fallbacks, so these descriptors still resolve against an unmigrated index.
compat.x11 gets the same isdir guard compat.xcb already had.
Add tests/check_cross_package_refs.lua to the lint job: it resolves every
`pkginfo.install_dir`/`build_dep` string against the identities the repository
actually declares. A reference into a foreign namespace (xim:python) is skipped,
and a ladder of spellings only needs one that resolves, so legacy fallbacks stay
legal. Matching is against the literal `package.name`, deliberately not a
normalised form — normalising the dots away would have called the broken
reference resolvable.
Verified with mcpp 0.0.106 against this branch: gui-stack 5/5, imgui-module 1/1,
imgui-window 1/1. Reverting the descriptor fix makes the lint flag exactly these
two references and nothing else.
0.0.104-0.0.106 skipped the SONAME alias whenever ninja was given explicit goal targets, which is exactly how `mcpp test` drives a build — so gui-stack, imgui-module and imgui-window failed here on any of those versions, with or without this branch's descriptor changes (probe PRs #121 and #122 reproduced it over unmodified descriptors).
The re-pin is for the soname-alias fix; SPEC-001 itself landed in 0.0.106 and `mcpp xpkg parse` has enforced the name rule since then. The version floor below still moves to 0.0.107 — that is the pin, not the rule's origin.
Runs the ffmpeg member alone, survives its failure, and prints the exit status and free disk on both sides — the job currently dies with a bare 127 and no mcpp output at all, right as the tarball finishes downloading.
mcpp returns the xlings child's exit code on this path and swallows its stderr, and the pinned xlings differs sharply across the versions under comparison (0.0.102 -> 0.4.51, 0.0.104+ -> 0.4.68/0.4.69) — which makes xlings, not mcpp, the thing this run needs to rule in or out.
…s my own relative-path mistake)
…e cmd.exe 8191-char cap
Only the workspace job survives, only its Windows matrix entry, and only the ffmpeg member — everything else here is noise while chasing the 127. The pin is mcpp's throwaway prerelease v0.0.107-dbg, built from branch debug/win127-instrumentation, which traces every ninja argv and every Windows popen command string from inside the process.
Member
Author
|
Answered: the Windows exit-127 was mcpp joining ~2281 ninja goal paths into one 50,781-character cmd.exe command line (cap 8191), so the command never ran and the 127 came from cmd.exe with no output. Fixed in mcpp 0.0.108 (mcpp-community/mcpp#285) by routing the goal set through build.ninja as a phony edge. These probes did their job — closing. |
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.
Diagnostic only — see the commit message. Close once the 127 is explained.