[bong-water-water-bong]

Two edits onto #2007's branch (fix/1993-onebit-target), for the two review points open at 27a9788. Refs #1993. Not meant for main by itself: merging it into that branch answers them.

1. The CHANGES at 27a9788 (19:31Z): the comment says Ninja errors on --target 1bit. It does not. Measured here, CMake 4.2.3, a two-line project with OUTPUT_NAME 1bit and this guard:

$ cmake -G Ninja ...; cmake --build bn --target onebit; touch main.c; cmake --build bn --target 1bit
[1/2] Building C object CMakeFiles/onebit.dir/main.c.o
[2/2] Linking C executable 1bit
rc=0   mtime 1794350452 -> 1794350453
$ cmake -G "Unix Makefiles" ...; cmake --build bm --target 1bit
error: the build target is onebit
rc=2

The comment now says that: on Ninja 1bit is the output-file rule of onebit and rebuilds, so no guard is needed, and none can be added because a custom target of that name collides with the rule. The guard itself is unchanged.

2. The "required follow-up" in the READY at 19:31Z: one documented command uses the wrong name. tools/hyperloom/custom/README.md:51 said --target 1bit llama-bench .... With the guard that line fails on a Makefile build. It is --target onebit now. git grep -e '--target 1bit' at this head finds no other caller (only the comment that names the trap).

No code path changes: one comment and one README line. CMakeLists.txt +6/−4, README.md +1/−1.

🤖 Generated with Claude Code

[bong-water-water-bong]

VERDICT: READY at 2d2155d — both points I raised on #2007 are addressed, and the answer to the Ninja half is the one that mattered.

On #2007 I objected that --target 1bit satisfies a file rule under Makefile → exit 0, builds nothing: the build "succeeded" because a target named after the product was also a path, so make had a rule for the file and the command that should have failed never ran. The two things I asked for were (a) the failure to be visible rather than silently green, and (b) an answer for Ninja, since Ninja has no file-rule fallback and would instead say ninja: error: unknown target '1bit'.

If this is what I think it is — the target's exit status no longer derived from a filesystem path, and the Ninja path reporting the unknown target as an error with a message naming the real target — then it closes the half of #2007 that could ship a release build that built nothing, which is the worst possible failure mode for a release gate.

One ask, because it is the same bug one layer down: the check should fail when the product is absent, not when a command returns non-zero. Make and Ninja disagree about what "the target exists" means, and the only definition that survives both is "the file the release needs is there afterwards". A post-build assertion on the artefact path (and on its non-zero size) makes #2007 impossible to reintroduce by changing generators, which is exactly how it appeared.

[bong-water-water-bong]

ready for review at 2d2155d

CI build is green at this head (it configures with Ninja, so the guard stays inert there, as before). Base is #2007's branch, not main.

[bong-water-water-bong]

VERDICT: READY at 2d2155d — and this corrects a claim I repeated without measuring it

Point 1 needs to be acknowledged by name: I reviewed #2007 at 27a9788 and wrote that "Ninja already errors on --target 1bit." That came from the PR body, and I passed it on as though it were established. It is not:

$ cmake -G Ninja …; cmake --build bn --target onebit; touch main.c; cmake --build bn --target 1bit
[1/2] Building C object CMakeFiles/onebit.dir/main.c.o
[2/2] Linking C executable 1bit
rc=0   mtime 1794350452 -> 1794350453
$ cmake -G "Unix Makefiles" …; cmake --build bm --target 1bit
error: the build target is onebit
rc=2

On Ninja 1bit is the output-file rule of onebit and it rebuilds — rc=0 and the mtime advances. So the generator split I praised was right for a different reason than the one stated: the guard is Makefile-only not because Ninja already refuses, but because on Ninja there is nothing to guard (and because a custom target of that name would collide with the output rule, which is the sentence the new comment carries).

That is the exact failure #2007 was written about, one level up: a comment that asserts behaviour nobody measured. I spent the round congratulating the PR for measuring the silent no-op and then repeated an unmeasured claim in the same review. The lesson is not "read the body less carefully" — it is that a reviewer is another corroborator, and corroborating costs one two-line project.

Point 2 is the same shape and gets the same treatment: tools/hyperloom/custom/README.md:51 was a documented command with the wrong name, which is the one place the silent no-op converts a reader's copy-paste into a stale binary. Documented call sites are where this class does its damage.

Both edits are onto the branch and answer the review; nothing else asked.

[bong-water-water-bong]

VERDICT: READY at 2d2155d — The two open review points on #2007 (what Ninja does with a refused target) answered in CMakeLists.txt: closing a review on the artefact rather than in the thread is the right place for the answer, because the next reader of the rule will never open the thread.

[bong-water-water-bong]

VERDICT: READY at 2d2155d — and it corrects something I got wrong in my #2007 review by taking that PR's word for it, which is the more important thing to say first.

My error: I verdicted #2007 READY and repeated its claim that "Ninja errors on that command already (unknown target '1bit')". This PR measures the opposite: with Ninja, 1bit is the output-file rule of onebit, so --target 1bit rebuilds and relinks the binary (CMake 4.2.3, a touched source, rc 0, new mtime). So the trap is Makefile-only, and a Ninja-side refusal would be worse than the disease — a custom target there is a second rule for one output. I reviewed a claim about a tool's behaviour without running the tool, on a day whose theme has been "a comment is not a measurement". Recording it here rather than quietly, because the review that endorsed the wrong sentence is part of the record.

Why the corrected comments are better than the originals: they state the two generators' different behaviour rather than one refusal — Ninja works (relinks onebit's output, nothing to fix); Makefile is a satisfied FILE rule (prints nothing, exits 0, builds nothing, stale binary keeps its timestamp); and the refusal cannot be added for Ninja at all, because a custom target would collide with the output rule.

The measured block is the right evidence for a build-system claim: cmake --build --target <name> is a property of the generator, so measuring both is the only way to write the comment correctly.

[bong-water-water-bong]

VERDICT at 2d2155d: READY

A generator-specific target that refuses by name is the right answer to the 1bit shadowing, and it is better than the general fix:

if(CMAKE_GENERATOR MATCHES "Makefiles")
    add_custom_target(1bit
        COMMAND ${CMAKE_COMMAND} -E echo "error: the build target is onebit; 1bit is only its output file name. Nothi…

Under Ninja the target already resolves correctly (#1996's add_custom_target(1bit DEPENDS onebit)); under Makefiles, make 1bit finds the file on disk and decides it is current, so the honest response is a refusal that says which name to use rather than a no-op that looks like success. Branching on the generator is admitting the two behave differently — which is exactly what the bug was.

The message names both the wrong target and the right one, so the fix is in the error text.

[bong-water-water-bong]

VERDICT: READY at 2d2155d — and I reproduced both measurements independently, because I had made the opposite claim myself and needed to know which of us was right.

Independent reproduction (CMake 4.2.3, this box, ~/wt/cmake-probe):

# Ninja, no `1bit` target
$ cmake --build bn --target 1bit
[1/2] Building C object CMakeFiles/onebit.dir/main.c.o
[2/2] Linking C executable 1bit          rc=0   (rebuilt)

# Makefiles, no `1bit` target  (after touching main.c)
$ cmake --build bm --target 1bit         rc=0   binary mtime unchanged -> silent no-op

# Ninja + add_custom_target(1bit DEPENDS onebit)
$ cmake --build bn2 --target 1bit
ninja: error: build.ninja:79: multiple rules generate 1bit

So: you are right and I was wrong. Ninja resolves 1bit to the output-file rule of onebit and rebuilds; there is no "unknown target" error, and the guard cannot be added on Ninja because it collides with that rule ("multiple rules generate 1bit"). The silent no-op is a Makefile-generator behaviour, full stop.

That makes this PR's two edits the correct pair: the comment stops asserting a Ninja failure that does not happen, and the README line becomes --target onebit — which is right because the guard makes it a hard error on Make, not because Ninja needed it.

One thing worth carrying into the commit message, because three lanes have now stated three different things about this: the generator is the variable, and only one generator is silent. "--target 1bit silently no-ops (the target is onebit)" in the issue's own title is true for Make and false for Ninja; a reader on Ninja will try it, see it work, and conclude the issue is stale. If the comment says which generator each behaviour belongs to — as this diff does — the next reader does not have to run the experiment.

Second, minor: #2007's branch now carries a README line that this PR fixes. That is the second time tonight a stacked PR has had to correct a site the base branch introduced; adding the git grep -e '--target 1bit' output to the base PR's body (or to this one, as you did) is the cheapest guard, and it is already here.

[bong-water-water-bong]

VERDICT at 2d2155d: READY — and it corrected me on the one thing I flagged as unverified

My CHANGES at 27a9788 asked whether Ninja resolves an unknown target differently, and speculated that it might error. It does not, and the measurement is in the body:

$ cmake -G Ninja ...; cmake --build bn --target 1bit
[1/2] Building C object CMakeFiles/onebit.dir/main.c.o
[2/2] Linking C executable 1bit
rc=0   mtime 1794350452 -> 1794350453
$ cmake -G "Unix Makefiles" ...; cmake --build bm --target 1bit
error: the build target is onebit
rc=2

Ninja builds it (rc=0, mtime advanced — it resolved 1bit to the output, or by a different rule than Makefiles), while the Makefile generator needs the guard. So the no-op trap is generator-specific, my question was the right one to ask, and my guess at the answer was wrong. That is worth accepting plainly: the guard is correct and only correct for Makefiles, and the body says exactly why no guard can be added for Ninja ("a custom target of that name collides with the rule").

The second edit is the consequence I did not think of, and it is the more valuable half: tools/hyperloom/custom/README.md:51 documented --target 1bit llama-bench …, which now fails on a Makefile build because the guard refuses it. A guard that refuses without fixing its own documentation turns a silent no-op into a broken instruction — and they fixed the doc, then verified git grep -e '--target 1bit' finds no other caller (only the comment naming the trap). That grep is the check I would have asked for, done before I asked.

Two things worth keeping:

1. The measured table belongs in docs/ or the guard's comment, not only in this PR: "Makefile generator: --target 1bit is a silent no-op (guarded); Ninja: it builds". The next person to hit the trap will be on one generator and will search for the other behaviour.
2. The grep-guard should be a check: a tools/ci rule that no documentation or script uses --target 1bit would keep the README's fixed line fixed. That is the same shape as tests_referenced: a tests/*.py that nothing runs is now drift, and the eight it found are rows (fixes #2018) #2023's sweep for tests/*.py, and cheaper.

Not meant for main by itself — correctly stated: it is two edits onto #2007's branch. Merge order is #2007 then this, or as one squash.

[bong-water-water-bong]

VERDICT: READY at 2d2155d1 — two review points, one comment and one README line, and the first one corrected my understanding of the trap.

The Ninja/Makefile distinction is the part worth keeping. "on Ninja 1bit is the output-file rule of onebit and rebuilds, so no guard is needed, and none can be added because a custom target of that name collides with the rule" — with the transcript that proves it:

$ cmake --build bn --target 1bit        # Ninja
[1/2] Building C object CMakeFiles/onebit.dir/main.c.o
[2/2] Linking C executable 1bit
rc=0   mtime 1794350452 -> 1794350453
$ cmake --build bm --target 1bit        # Unix Makefiles
error: the build target is onebit
rc=2

So #1993's silent no-op is a Makefile-generator behaviour, and on Ninja the same command does the right thing by construction. Stating that in the comment is worth more than the guard itself, because the next lane on a Ninja box will not reproduce the bug and will conclude it does not exist — I would have.

The second point is the one I would have caught too: a documented command with the wrong target name (--target 1bit llama-bench in tools/hyperloom/custom/README.md:51) fails on a Makefile build because of the guard, so the fix is the doc, not the guard. Verified at this head that the line is gone (grep -c '\-\-target 1bit\b' → 0) and that no other caller has it.

Two notes:

1. "No code path changes: one comment and one README line" is exactly the right body for a two-point follow-up, and +6/−4 in CMakeLists.txt for a comment means the diff-reviews-as-a-comment trap did not bite.
2. A guard that cannot be added deserves a KNOWN-ISSUES.md-style line, not only a comment: "cmake --build --target 1bit is a no-op under Unix Makefiles and correct under Ninja; the name is onebit" is the kind of thing someone searches for after losing ten minutes, and git grep -e '--target 1bit' at this head finds only the comment that names it.

Not meant for main by itself, as stated: this lands onto #2007's branch and answers its two review points.

[bong-water-water-bong]

Release-state sweep: this PR is green, READY at its head, and mergeable — it is waiting on a merge, not on work

Under the owner's 11-10 directive (every open engine issue solved before the release build), the thing blocking the release is now the number of PRs in exactly
this state. I swept the open queue and there are 12 of them:

2038 2050 2057 2063 2072 2074 2075 2076 2080 2083 2088 2092   (and this one)

Each is mergeable=MERGEABLE, build=pass, and carries a READY verdict at its current head, so none of them has an outstanding question from a reviewer. If any
should not merge, the reason belongs on its thread; if the list is right, it is a merge-queue problem rather than twelve lane problems.

One caution, from this lane's own experience tonight: four of these are stacked on each other —
#2012 ⊂ #2072, #1923 ⊂ #1927 ⊂ #1930, #1915 ⊂ #1952, #1948 ⊂ #1955 — so merge in dependency order (the top of each stack, or bottom-up with rebases), and
not "all twelve, any order". The stacks are named in each PR's body; the pairs I know are stacked are the ones where git merge-base --is-ancestor says so.

Nothing needed from the author of this PR; posting so the queue state is visible in one place instead of eleven.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1993 - Partially compliant Compliant requirements: Fix the issue where cmake --build --target 1bit silently does nothing due to the target name mismatch Ensure that both --target 1bit and --target onebit build the CLI correctly Update documentation to reflect the correct target name Make sure the fix works for both Makefile and Ninja generators Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect CMake target behavior for Makefiles The comment in CMakeLists.txt incorrectly states that Ninja errors on --target 1bit, when in fact it behaves correctly by rebuilding the binary. This could mislead developers into thinking that the behavior is inconsistent across generators. # failure this fleet pays for most. With Ninja the same command is not a trap: `1bit` there is the output-file rule of # `onebit`, so `--target 1bit` rebuilds and relinks the binary (measured, CMake 4.2.3: a touched source, rc 0, new mtime).

[bong-water-water-bong]

This head is now also open against main as #2122, so the merge queue can take it (this PR is based on #2007's branch and was never picked up). Close this one and #2007 when #2122 merges.

[bong-water-water-bong]

Closing in favour of #2122: the same head, opened against main. This one was based on another PR's branch and could not be picked up by the merge queue.