build: derive TEST_BINS by wildcard — stop manufacturing Makefile conflicts - #731
Merged
Conversation
…nflicts TEST_BINS was one long shared line listing 28 gates. Every PR that adds a test appended to that same line, so any two such PRs conflicted in the Makefile by construction — even when they touched entirely unrelated parts of the engine. That is not a hypothetical. c/Makefile appears in 26 of the 40 currently open PRs, and #386 hit this specific conflict twice across its rebases: "One conflict (both sides appended a test binary to TEST_BINS)" Adding a gate now means adding your tests/test_*.c and its own build rule, which land in different places in the file. Nobody edits a line somebody else is also editing. TEST_EXCLUDE keeps the four test_*.c that were never default gates, plus test_uring which is appended conditionally on Linux just below — a bare wildcard would have promoted it to every platform. Verified the derived set is byte-identical to the hand-written one (29 entries including test_uring on Linux, same names), `make test-c` passes, and a freshly created tests/test_*.c is picked up without touching this line. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JustVugg
added a commit
to monotophic/colibri
that referenced
this pull request
Jul 31, 2026
…the wildcard Resolved by a maintainer rather than asking for an eleventh rebase, because the conflict was caused by a merge made minutes earlier and the resolution deletes work rather than adding any. The only conflicting hunk was TEST_BINS. This branch appended test_cap_precedence and test_ssd_probe to the hand-written list; dev (JustVugg#731) now derives that list with a wildcard, specifically so that adding a test stops conflicting with every other PR that adds a test. So the branch's append is dropped: both tests are discovered automatically, and their build rules — which merged cleanly, in a different part of the file — are untouched. Verified: TEST_BINS goes from 29 to 31 entries, both new gates included; `make test-c` passes; test_cap_precedence and test_ssd_probe both report ok. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Jul 31, 2026
JustVugg
added a commit
that referenced
this pull request
Jul 31, 2026
build: derive TEST_BINS from the build rules, not the .c files (corrects #731)
JustVugg
added a commit
to monotophic/colibri
that referenced
this pull request
Jul 31, 2026
Corrects JustVugg#731, which globbed tests/test_*.c. That was wrong in the opposite direction from the hand-written list it replaced: it promoted files that deliberately have no build rule into gates. On dev the four such files were known and excluded by name, so the set came out identical and the mistake was invisible; on a contributor branch it is not. Merging dev into JustVugg#529 promoted that branch's tests/test_fp8_e2e_loader.c -- a file monotophic has but never gated -- and the build failed on an undefined reference to sqrtf. Having a build rule is the honest definition of a gate, so derive the list from the rules. TEST_EXCLUDE drops from five entries to one: test_uring, which has a rule but is Linux-only and is appended conditionally just below. The property that motivated all of this is unchanged and now stronger: adding a gate means adding your .c and its own rule, which land in different places in the file. There is no shared list left to conflict on at all. Verified identical to current dev (31 entries, same names) and make test-c green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5 tasks
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.
A structural fix for the rebase churn, not a cleanup.
The problem
TEST_BINSwas a single shared line listing 28 test gates. Every PR that adds a test appended to that same line, so any two such PRs conflicted inc/Makefileby construction — even when they touched completely unrelated parts of the engine.This is measurable rather than theoretical:
c/Makefileappears in 26 of the 40 currently open PRs. And #386 hit this exact conflict twice while being rebased:Every one of those rebases was real work by a contributor, caused by a line that did not need to be shared.
The fix
Derive the list with a wildcard. Adding a gate now means adding your
tests/test_*.cand its own build rule — those land in different places in the file, so they do not collide.TEST_EXCLUDEholds the ones that are deliberately not default gates, each with its reason in a comment:test_uring— Linux-only, appended conditionally just below. A bare wildcard would have promoted it to every platform; this is the behaviour change the exclusion prevents.test_vk_mxfp4— needs a Vulkan build (VK=1) to link the backend.test_fse,test_tok,test_tok_kimi— no build rule in the Makefile; never were gates.Verification
test_uringon Linux, same names. Compared by rendering$(TEST_BINS)from both the old and new Makefile and diffing — no differences.make test-cpasses.tests/test_zz_probe.cis picked up automatically, without touching any shared line.One file, build system only. No engine code, no behaviour change.