Conversation
The shipyard pkg no longer writes the CMake user package registry, and
MavericksShipyardConfig.cmake now refuses any cmake but shipyard-cmake.
msc.sh is replaced wholesale by shipyard's canonical template (conventions check
17 compares it byte for byte): $SHIPYARD_SCRIPTS in CI, else ask shipyard-cmake
where find_package(MavericksShipyard) lands.
It was not the only locator. package.sh and scripts/guard.sh each carried their
own four-entry fallback chain, and both named
$HOME/.local/share/cmake/MavericksShipyard/scripts -- the prefix a `cmake
--install` used to produce, which the pkg does not create. Neither read
~/.cmake/packages, so neither looked like a registry reader; both were about to
resolve nothing off CI. package.sh's chain also OVERWROTE the $SHIPYARD msc.sh
had already set eleven lines earlier. Both now use $SHIPYARD.
guard.sh keeps its exit 4 for the case that is genuinely its own -- shipyard
found, assert_binary_compatible.sh missing from it -- which is distinct from
msc.sh's "no shipyard at all".
Four call sites move to shipyard-cmake: the updater configure and --build in
release.yml, build.sh's stdlib configure, and the `build it: cmake --build
build/updater` recipe package.sh prints when the updater is absent. That last one
sits behind a bare "(" that conventions check 18 deliberately skips, so no gate
would have reported it. build.sh's prerequisites line named plain cmake; it now
names the shipyard pkg.
BREAKING CHANGE: builds now require the shipyard pkg (it provides
/usr/local/bin/shipyard-cmake). Do not merge until shipyard has landed bc3082a.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GTxFde2TJMmp5p64DhvDSK
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
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.
Part of the 14-repo shipyard-cmake flag day.
Do not merge until shipyard has landed bc3082a. Until then
shipyard-cmakeexists on no runner, so this PR's own CI is expected to fail at the first configure. That red is the merge-order hold, not a defect.What changed
msc.sh(repo root — check 17 acceptsbuild/msc.shor a rootmsc.sh, and this repo's lives at the root) replaced wholesale by shipyard's canonical template. Verifiedbyte-identical.package.sh:26-35andscripts/guard.sh:14-23each carried their own four-entry fallback chain, and both named$HOME/.local/share/cmake/MavericksShipyard/scripts— the prefix acmake --installused to produce, which the pkg does not create. Neither read~/.cmake/packages, so neither was flagged by check 16 or by a registry sweep; both were about to resolve nothing off CI.package.sh's chain also overwrote the$SHIPYARDthatmsc.shhad set eleven lines earlier. Both now use$SHIPYARD.scripts/guard.shkeeps itsexit 4for the case that is genuinely its own — shipyard found,assert_binary_compatible.shmissing from it — which is a different failure frommsc.sh's "no shipyard at all" (exit 1). Both were proven by running them.shipyard-cmake: the updater configure and--buildinrelease.yml,build.sh:143's stdlib configure, and thebuild it: cmake --build build/updaterrecipepackage.shprints when the updater is absent.build.sh's prerequisites line named plaincmake; it now names the shipyard pkg. Tworelease.ymlcomments named the user package registry and${MavericksShipyard_SCRIPTS}(a variable this PR removes); they now name the pkg and$SHIPYARD_SCRIPTS.The one the gate cannot see
package.sh:55prints its recipe from inside(... build it: ...). Check 18 deliberately treats a bare(as not command position, so it was invisible to the gate. Found by sweeping every tracked file, not just the gate's subset.Verification
check-family-conventions.sh(fromshipyard-cmake-collapsed): 4 failures -> ok, exit 0.git ls-files: clean, no exceptions needed. A wider sweep leaves only prose (MANIFEST's "key cmake flags", twobuild.shcomments about CMake build trees)..local/share/cmakepath and noMavericksShipyard_SCRIPTSsurvives anywhere in the tree.check-shell-portability.sh,check-comments.sh,sh -non every tracked*.sh, all three workflows parse as YAML.scripts/guard.shrun three ways: with$SHIPYARD_SCRIPTSset it reaches the shared guard; with an empty shipyard it exits 4 with its own message; with no shipyard it exits 1 frommsc.sh.install@v1's default mode already putsshipyard-cmakeonPATH.🤖 Generated with Claude Code
https://claude.ai/code/session_01GTxFde2TJMmp5p64DhvDSK