fix: the image build stages corHttp too - #68
Merged
Conversation
make -C /root/git/corLibs di -> exit 2 corLibs is not a library, it is the umbrella that builds ALL of them in dependency order — so adding corHttp to its COR_DIRS made a hard dependency of every place that stages the repos by an explicit list. It was added to one (coraine's own makefile) and not to the three others. docker/vendor-libs.sh — THE BREAK. The Cor-Libs are exported from the local clones rather than cloned in the container, and corHttp was not in that list, so the umbrella hit a directory that was not there. It fails at the BUILD of a lib the default image does not even link, which is why "we do not use corHttp in this build" is not a reason to leave it out. .github/workflows/release.yml — would have failed at the next RELEASE, not here: the cross-repository token names the repos it may write to, and the tagging step names the ones to tag. corHttp joins both. It is in the second tag group, with corTest and corLibs — the ones that are part of reproducing a build without being linked into it — and also in the manifest-driven case, so a builtin build tags it from the exact sha. tagRepo is idempotent, so being in both is free. stackManifest.sh — corHttp ONLY when COR_HTTP_SERVER=builtin. That file answers "what is linked into this binary", and on an mhd build corHttp is built and not linked; listing it would be a claim about the binary that is not true of it. The makefile passes the variable down so the generated coraineStack.h is right for either build. Verified both ways. And two comments that had gone false: the Cor-Libs stopped being private when they moved to the SEAMWARE org, so "a container cannot clone them" is no longer why they are vendored. The reason now is that a clone would build whatever `main` happens to be, rather than the tree the developer running `docker build` is looking at. Verified: `./docker/vendor-libs.sh && docker build -f docker/Dockerfile .` completes, and the image starts and answers — /version lists the twelve linked libs (corHttp correctly absent), /build says httpServer=mhd, POST 201, GET 200. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37
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.
mainis red for image builds.make -C /root/git/corLibs diexits 2.corLibsis not a library — it is the umbrella that builds all of them independency order. Adding
corHttpto itsCOR_DIRS(corLibs#7) therefore made ahard dependency of every place that stages the repos by an explicit list, and it
was added to one of them (coraine's own makefile) and not to three others.
docker/vendor-libs.shLIBS, so the umbrella hit a missing directory. It fails at the build of a lib the default image does not even link — which is why "we don't use corHttp in this build" is not a reason to leave it out..github/workflows/release.ymlstackManifest.shCOR_HTTP_SERVER=builtin— that file answers what is linked into this binary, and an mhd build does not link it. The makefile passes the variable down socoraineStack.his right either way.Also corrects two comments that went stale when the repos moved to SEAMWARE: they
are not private any more, so "a container cannot clone them" is no longer why
they are vendored. The reason now is that a clone would build whatever
mainhappens to be rather than the tree the developer is looking at.
Verified locally:
./docker/vendor-libs.sh && docker build -f docker/Dockerfile -t coraine:local .completes, and the image starts and answers —
/versionlists the twelve linkedlibs (corHttp correctly absent),
/buildsayshttpServer: mhd, POST 201, GET 200.🤖 Generated with Claude Code
https://claude.ai/code/session_01TGatXwrHx1CreL49sCuS37