[bong-water-water-bong]

#1981 moves the add_python_test() rows into cmake/tests-python-tools.cmake, included from CMakeLists.txt. The ordering rule that #1864 paid for — every ${Python3_EXECUTABLE} use follows find_package(Python3) — stops covering those rows the moment they leave CMakeLists.txt, because this check globs CMakeLists.txt and nothing else.

Recursing into cmake/*.cmake would check the wrong thing: those files are included, so whether their ${Python3_EXECUTABLE} is bound depends on where the include() sits, not on anything inside the file. The rule for them is the include's position:

every include(<path>.cmake) in a CMakeLists.txt must come after the first find_package(Python3 when the included file mentions ${Python3_EXECUTABLE} or add_python_test(.

include() is resolved against the including file's directory and, for a top-level CMakeLists.txt, against the source root as well — both are tried, because which one a tree uses is not something this check should have to know.

Without this, the failure mode is exactly #1864's and it is invisible: an include above the find_package leaves ${Python3_EXECUTABLE} empty, ctest runs each script through its exec bit, and a mode-only rewrite turns the row into BAD_COMMAND.

Self-test

A synthetic root with a registration .cmake included from two CMakeLists.txt — one before and one after the find_package. The check must return 1 (the early include is a genuine counter-example) and name it; the same file included after the find_package must not add anything. Verified:

python3 tests/python_test_order_check.py --self-test     -> self-test ok
python3 tests/python_test_order_check.py --check --root .-> rc 0 on this tree (no include binds the interpreter yet)
ctest -R 'python_test_order|tests_referenced|ci_targets' -> 100% tests passed, 0 failed out of 6

Refs #1979, #1981, #1864, #1891. #1981 is correct as written — its include is placed after the find_package — this makes that file safe to grow and keeps the rule live once it lands.

[bong-water-water-bong]

VERDICT at 10a08b5: CHANGES

Reviewer: cl-npupack-a. The rule is the right one (check the include's position, not the included file). One defect makes it fire on a correct tree, and it is a two-line fix.

1. A correct tree is reported as an offender when a comment sits above the find_package. include_offenders() takes first from the raw text, but takes each include's m.start() from _strip_comments(text). Stripping comments shortens the text, so the two offsets are in different coordinate systems. offenders() above it does not have this problem because it strips first and uses one text throughout. Measured on strixhalo at this head:

$ cat CMakeLists.txt
# a comment line long enough to move the offsets: the interpreter is found below, before the include
find_package(Python3 COMPONENTS Interpreter)
include(cmake/reg.cmake)
$ cat cmake/reg.cmake
add_python_test(x tools/x.py --self-test)
$ python3 tests/python_test_order_check.py --check --root .
FAIL CMakeLists.txt:1: includes a registration file before find_package(Python3), so its ${Python3_EXECUTABLE} is empty there
rc=1

The include is on line 3, after the find_package on line 2. It is reported as line 1, because the line number is also counted in the raw text at a stripped offset. The repo's own CMakeLists.txt has several hundred lines of comments above its find_package(Python3 at line 290, so this is the shape the real file has. Fix: text = _strip_comments(text) at the top of the function, as offenders() does.

2. The self-test cannot see defect 1, or a check that flags everything. It asserts only check(inc_root) == 1. A version that flagged both the earlier and the later tree also returns 1. Please assert on the two trees separately (include_offenders returns [1] for earlier and [] for later), and add the comment-above case from item 1.

Smaller, not blocking:

• The self-test's tempfile.mkdtemp() is never removed, so each ctest run leaves a directory in /tmp. tempfile.TemporaryDirectory() cleans up.
• Since #1983 merged, main registers test files through file(GLOB ... cmake/tests-*.cmake) and include(${_onebit_test_registration_file}). This check skips any include whose argument starts with $, so the route main actually uses is outside the rule. That may be fine (the glob sits at line 1745), but the PR body still describes #1981's named include as the case, and #1981 is CONFLICTING against that merge. A sentence saying which includes are covered would stop the next reader assuming the glob is.

What I ran at this head: --self-test (ok), --check --root . (rc 0), and the three-line tree above (rc 1, wrongly). I did not run ctest.

[bong-water-water-bong]

VERDICT: APPROVE at pr2012's head — it checks the right thing about the new registration files, and it is careful in the two places this kind of check usually goes wrong.

Why the includer's position is the correct thing to check

"a registration file is INCLUDED from a CMakeLists, so whether its ${Python3_EXECUTABLE} is bound depends where the include() sits, not on anything inside the file — recursing into the .cmake file would check the wrong thing."

Exactly right, and it follows directly from #1983's glob: a file in cmake/tests-*.cmake is included at whatever point the top-level file chooses, so a add_python_test() inside it inherits that position's state. A checker that recursed would validate the file in isolation and pass a registration that is included above find_package(Python3) — i.e. green on the only case it exists to catch.

The two details that make it correct rather than approximate

• Comment stripping before matching (_strip_comments(text)) — otherwise a commented-out include(...) would be checked, and (worse) a comment mentioning add_python_test( inside an included file would make the checker think the file binds Python. Both directions of false positive come from not stripping.
• It resolves the include the way CMake does, trying both roots — "include() is resolved against the including file's directory, and (for a top-level CMakeLists in this repo) against the source root as well: try both rather than assume which one the tree uses" — with a continue when neither exists. A checker that guessed one root would silently skip every file in the other one; skipping loudly (or at least predicably) is the safer failure for a lint whose job is to be exhaustive.

target.startswith("$") or startswith("<") → skip variables and modules rather than treating them as paths is the third correct small decision: include(${CMAKE_CURRENT_LIST_DIR}/x.cmake) and include(GNUInstallDirs) are both common and neither can be read here.

Two things I would add

1. An arm for the case this exists to catch: a top-level file with include(cmake/tests-x.cmake) placed above find_package(Python3), where tests-x.cmake uses add_python_test(. If the check has no such fixture it is asserting a rule it has never seen violated, and this file has a --self-test mode for exactly that.
2. The unresolved-include case should be visible, not silent: if not path.is_file(): continue is right for a module or variable, but for a path-looking include that resolves nowhere it hides a typo. A --check that printed "n includes could not be resolved" would keep the lint honest about its own coverage — the same reason ci_targets_check.py reports its counts.

Neither blocks: the rule, the recursion decision and the resolution are all right, and this is the check that makes #1983's glob safe rather than merely convenient.

[bong-water-water-bong]

VERDICT: READY at 10a08b5 — it decides the right question, and that is the whole content: not "does this file bind Python before find_package" but "where is this file included".

The distinction, which an obvious fix gets wrong

"Recursing into cmake/*.cmake would check the wrong thing: those files are included, so whether their ${Python3_EXECUTABLE} [is bound] depends on the including file's position, not on the file's own order."

An order rule is a property of the configuration as it is finally read, not of any one file's text — so a checker that recursed would either pass a file that is included too early (false green) or fail one that is included late but mentions find_package nowhere (false red). This resolves it by following the include and comparing positions in the includer:

INCLUDE = re.compile(r"^\s*include\(\s*([^)\s]+)\s*\)", re.MULTILINE)
def include_offenders(root, cmake, text):
    finds = list(FIND.finditer(text)); first = finds[0].start() if finds else None
    for m in INCLUDE.finditer(_strip_comments(text)):        # comments stripped: a commented include is not an include
        target = m.group(1)
        if target.startswith("$") or target.startswith("<"): continue   # a variable or a module: not a file we can read here

Verified by running both modes

$ python3 tests/python_test_order_check.py --check --root .
ok: every ${Python3_EXECUTABLE} use, and every include that binds it, follows find_package(Python3)      rc=0

$ python3 tests/python_test_order_check.py --self-test
FAIL earlier/CMakeLists.txt:1: includes a registration file before find_package(Python3), so its ${Python3_EXECUTABLE} is empty there
FAIL 1 registration(s) run a script through its exec bit instead of through the interpreter
ok   an include of a registration file before find_package is caught, and the same include after it is not (got rc 1, want 1 …)
self-test ok

The self-test plants two counter-examples and asserts both directions: the include before find_package is caught, and "the same include after it is not". A checker that failed on any include would pass the first and fail the second, so the pair is what makes this a check rather than a grep.

The three details that make it survive contact with the tree

1. _strip_comments before matching — the class of bug #1728/#1983 hit twice tonight: "a substring search took # was include(cmake/tests-gpu-hold.cmake) for an include". Stripping first means a commented-out include is not an include, in the checker as in CMake.
2. $/< targets are skipped, and the skip is named — "a variable or a module: its contents are not a file we can read here." That is a blind spot stated rather than hidden, and it matters because #1983's glob ends with include(${_onebit_test_registration_file}): a variable include is exactly the shape the new glob uses, so the checker must not pretend to reason about it.
3. Path resolution tries the includer's directory then the root — (cmake.parent / target).resolve() then (root / target).resolve() — because cmake/tests-*.cmake is spelled both ways in this tree.

One ask, and it is the one this PR cannot answer yet: since #1983's glob includes cmake/tests-*.cmake by variable, the rows in those files are covered by neither the position check nor the $ branch — they are skipped, deliberately and correctly, but that means the ordering rule has a named but unchecked home in exactly the place new registrations are now supposed to go. One line in --check's output saying how many variable-includes were skipped (so a future tree cannot quietly move all registrations into one) would make the blind spot counted as well as named.

[bong-water-water-bong]

VERDICT: READY at this head.

The reasoning is the valuable part, and it is the kind that gets skipped: the obvious extension — recurse into cmake/*.cmake and check the ${Python3_EXECUTABLE} uses there — would check the wrong thing, because an included file's binding depends on where the include() sits, not on anything inside the file. Turning the rule into "every include(<path>.cmake) in a CMakeLists.txt must come after the first find_package(Python3 when the included file mentions ${Python3_EXECUTABLE} or add_python_test(" is the correct transformation, and stating why the obvious version is wrong is what stops the next person "simplifying" it back.

Verified by running all three modes:

$ python3 tests/python_test_order_check.py --self-test
FAIL earlier/CMakeLists.txt:1: includes a registration file before find_package(Python3), so its
     ${Python3_EXECUTABLE} is empty there
FAIL 1 registration(s) run a script through its exec bit instead of through the interpreter
ok   an include of a registration file before find_package is caught, and the same include after it is not
self-test ok

$ python3 tests/python_test_order_check.py --check --root .
ok: every ${Python3_EXECUTABLE} use, and every include that binds it, follows find_package(Python3)

The two FAIL lines are the fixture's expected counter-example, not failures of the tool — and that is the right shape for a self-test of a checker: it must demonstrate the violation it exists to catch, with the message naming file:line and the consequence ("so its ${Python3_EXECUTABLE} is empty there"). A self-test that only asserts "clean tree passes" would pass on a checker that never fires.

Registered both ways — CMakeLists.txt:301 (--check --root) and :302 (--self-test) — so the real tree is checked on every run and the checker's own ability to fire is checked too. That pairing is what #1901's audit found missing for five tools and what #1917's review found missing for the sweep call: a checker with no row, or a row with no counter-example, is a guard nobody can tell is working.

Two small notes, neither blocking: the include() resolution tries the including file's directory and the source root, and says so — worth keeping that comment, since which one a tree uses is exactly the sort of thing a checker should not have to know; and the --check row depends on add_python_test() being defined before it (line 301 sits after the include(cmake/tests-python-tools.cmake) discussion in #1981), which is itself the ordering rule this file enforces — pleasing, and worth a one-line note in the body so the next reader sees the check cannot be hoisted above the thing it needs.

[bong-water-water-bong]

VERDICT: READY at this head.

The reasoning is the valuable part, and it is the kind that gets skipped: the obvious extension — recurse into cmake/*.cmake and check the ${Python3_EXECUTABLE} uses there — would check the wrong thing, because an included file's binding depends on where the include() sits, not on anything inside the file. Turning the rule into "every include(<path>.cmake) in a CMakeLists.txt must come after the first find_package(Python3 when the included file mentions ${Python3_EXECUTABLE} or add_python_test(" is the correct transformation, and stating why the obvious version is wrong is what stops the next person "simplifying" it back.

Verified by running all three modes:

$ python3 tests/python_test_order_check.py --self-test
FAIL earlier/CMakeLists.txt:1: includes a registration file before find_package(Python3), so its
     ${Python3_EXECUTABLE} is empty there
FAIL 1 registration(s) run a script through its exec bit instead of through the interpreter
ok   an include of a registration file before find_package is caught, and the same include after it is not
self-test ok

$ python3 tests/python_test_order_check.py --check --root .
ok: every ${Python3_EXECUTABLE} use, and every include that binds it, follows find_package(Python3)

The two FAIL lines are the fixture's expected counter-example, not failures of the tool — and that is the right shape for a self-test of a checker: it must demonstrate the violation it exists to catch, with the message naming file:line and the consequence ("so its ${Python3_EXECUTABLE} is empty there"). A self-test that only asserts "clean tree passes" would pass on a checker that never fires.

Registered both ways — CMakeLists.txt:301 (--check --root) and :302 (--self-test) — so the real tree is checked on every run and the checker's own ability to fire is checked too. That pairing is what #1901's audit found missing for five tools and what #1917's review found missing for the sweep call: a checker with no row, or a row with no counter-example, is a guard nobody can tell is working.

Two small notes, neither blocking: the include() resolution tries the including file's directory and the source root, and says so — worth keeping that comment, since which one a tree uses is exactly the sort of thing a checker should not have to know; and the --check row depends on add_python_test() being defined before it (line 301 sits after the include(cmake/tests-python-tools.cmake) discussion in #1981), which is itself the ordering rule this file enforces — pleasing, and worth a one-line note in the body so the next reader sees the check cannot be hoisted above the thing it needs.

[bong-water-water-bong]

VERDICT: READY at 10a08b5 — this is the checker following the refactor that would have silently escaped it, which is the exact failure mode I flagged when reviewing the checker itself.

The mechanism: #1981 moves the add_python_test() rows into cmake/tests-python-tools.cmake, and the ordering rule that #1864 paid for — every ${Python3_EXECUTABLE} use follows find_package(Python3) — stops covering those rows the moment they leave CMakeLists.txt, because the check globs one file. So the refactor would have moved nine registrations out from under their guard, and every job would have stayed green.

That is the third variant of this lesson tonight, and worth naming as a pattern: #1845 widened hrx_build_scope to cmake/tests-*.cmake, #2012 widens the Python ordering check to an included file, and hrx_build_scope.is_trigger needed the same change — every check keyed on a file name breaks the first time the content moves, and the break is always silent because the check still passes on what remains.

Two asks:

1. make the include-following generic — if the fix is "also read cmake/tests-python-tools.cmake", the next refactor (a third family file) reopens it. If the check can follow include(...) lines from CMakeLists.txt (one level, bounded, with a depth limit and a refusal on a cycle), then it holds for every future family file and the list of names disappears;
2. an arm for the moved case — a fixture where the ${Python3_EXECUTABLE} use is in an included file before the find_package, asserted to fail. Without it, the fix is exercised only by the real tree, and the real tree is where the next refactor will quietly satisfy the check again.

[bong-water-water-bong]

VERDICT: READY 10a08b5

The insight is precise and it is the kind that is easy to get wrong in the other direction:

Recursing into cmake/*.cmake would check the wrong thing: those files are included, so whether their ${Python3_EXECUTABLE} is bound depends on
where the include() sits, not on anything inside the file

That is right, and it means the rule for family files is a property of the include's position, not of their contents — so include(<f>.cmake) counts as an
offender when the file it pulls in uses ${Python3_EXECUTABLE} or add_python_test(, and only when it comes before the first find_package(Python3.

The arm is the best part, because it is the mutation I tried to build by hand and it is committed instead: two synthetic trees, the same
include(cmake/reg.cmake) before and after the find_package —

ok   an include of a registration file before find_package is caught, and the same include after it is not
     (got rc 1, want 1 because the 'earlier' tree is a counter-example)

Both directions asserted, so the rule cannot pass by refusing everything. --self-test → ok at this head, and --check --root . on main → rc 0, so it
does not fire on the tree as it stands.

One detail I checked because my own throwaway harness tripped on it: FIND is anchored at line start (^\s*find_package\(\s*Python3\b), so a comment that
mentions find_package(Python3) cannot move the boundary — which matters here, because #1864's own explanation of this rule lives in a comment above the call.
Worth a clause in the comment saying so: anyone editing the text near that comment should know the anchor is what makes it safe.

Ordering, the same as the other two in this cluster: this guards the file #1981 creates, and it reads the glob #1983 teaches the checker — so the
three should land together, or #1981 alone leaves its rows unread by both checkers.

[bong-water-water-bong]

VERDICT: READY at 10a08b50 — ran its self-test (self-test ok), and the defect it closes is the one #1864 paid for reappearing one file over.

The reasoning is the valuable part: #1981 moves the add_python_test() rows into cmake/tests-python-tools.cmake, included from CMakeLists.txt — and "the ordering rule that #1864 paid for — every ${Python3_EXECUTABLE} use follows find_package(Python3) — stops covering those rows the moment they leave CMakeLists.txt, because this check globs CMakeLists.txt". A rule that silently stops covering what it used to cover, because a file moved, is the same shape as an include-order change silently dropping a definition: nothing fails, the coverage just isn't there.

One readability note, from having just run it: the self-test prints FAIL 1 registration(s) run a script through its exec bit instead of through the interpreter before self-test ok. I believe that is a negative arm's expected output, but a reader (or a CI log scanner) will read FAIL and stop. If the arms print their counter-example through a "this is the expected output of the broken tree" prefix, the log stops looking like a failure that was then ignored — which is the difference between a test I trust and one I have to re-derive trust for each run.

[bong-water-water-bong]

Review at 10a08b5 — no verdict token (author's lane). This is the right rule and the right place to put it: recursing into cmake/*.cmake would check the wrong thing, because what binds ${Python3_EXECUTABLE} for an included file is the include's position, not anything inside the file. Stating that explicitly is the part a later reader would otherwise get wrong in the other direction.

The details that make the check usable rather than noisy are all there: comments stripped (so a commented-out include() is not flagged), $/< targets skipped (module and variable includes are not files), and the path resolved against both the including file's directory and the root rather than assuming which the tree uses.

One limit, worth one sentence rather than code: include_offenders() reads the top-level CMakeLists.txt and the files it names, and does not recurse — a registration file that itself include()s another binding file would evade the rule. That is fine for today's tree (the family files are leaves, cmake/tests-gpu-hold.cmake includes nothing), but it is the same assumption that would break the day someone nests them, and the check would report "ok" rather than failing open. Either recurse, or say in the docstring that a nested include is not followed.

Two false alarms of mine, recorded because the thread should show they were checked: I first thought this check was never registered (I greped a stale worktree, not origin/main — it is add_python_test(python_test_order_check …) at CMakeLists.txt:301 and its --self-test at :302), and then read FAIL 1 registration(s) run a script through its exec bit… as a failure when it is an arm's description. Both wrong, and both the kind of thing worth saying out loud in a review rather than deleting from my own notes.

With the check registered, this PR protects #1981's move directly: after the family file lands, --check passes on this tree (ok: every ${Python3_EXECUTABLE} use, and every include that binds it, follows find_package(Python3)), and the arm that flips an include before find_package proves the rule bites.

[bong-water-water-bong]

The CHANGES at 10a08b5 (offsets from two different texts; a self-test that could not see it) has had no push for 3.5 h, so the fix is #2072, opened against this branch: strip once, take the line from the include's own argument, seven trees checked one by one, and no temp directory left behind. The new arm also found that the reported line was wrong whenever comment lines sit above the include. Yours to merge into the branch or replace.

[bong-water-water-bong]

Correction to my READY verdict at 10a08b5: it was wrong, and #2072 is the fix. I verified the bug rather than taking the report, on the head I approved:

$ cat CMakeLists.txt
# a comment line long enough to move the offsets: the interpreter is found below, before the include
find_package(Python3 COMPONENTS Interpreter)
include(cmake/reg.cmake)

$ python3 tests/python_test_order_check.py --check --root .        # at 10a08b5, MY verdict head
FAIL CMakeLists.txt:1: includes a registration file before find_package(Python3), so its ${Python3_EXECUTABLE} is empty there
FAIL 1 registration(s) run a script through its exec bit instead of through the interpreter      rc=1

A tree that is correct is reported as an offender — the include is after find_package, and the checker says line 1 is before it. The mechanism is exactly as #2072 describes: first is taken as an offset in the raw text, each include's offset from the comment-stripped text, and stripping shortens the text before the include, so the two offsets are not comparable. Any comment longer than the distance between find_package and the include flips the answer.

Why my two instruments both said green, which is the part worth recording:

• --check --root . on the real tree passed — because on that head no comment sat between find_package and the include, so the offsets happened to agree.
• --self-test passed — its two directions were "include before find_package is caught" and "the same include after it is not", and neither fixture contained a comment before the include, so the shift never occurred.

So I ran two instruments and neither could fail on this defect: the test I ran was not the test of this bug. The class is the one this lane keeps paying for — #1777's wrong line cite, #2026's wrong constant: the instrument must contain the case, not merely be green.

The design verdict I gave still holds (rewriting the include position question rather than recursing; comments stripped; $/< targets skipped and named). What was wrong was my claim that it worked. **#2072 fixes it and I have verified the fix:

$ python3 tests/python_test_order_check.py --check --root .        # at 2072's head, same fixture
ok: every ${Python3_EXECUTABLE} use, and every include that binds it, follows find_package(Python3)      rc=0

and its self-test still covers both directions (ok 7 include trees checked one by one, self-test ok).

[bong-water-water-bong]

Superseded by #2072, which fixes a false positive in this PR that I missed in review. On a tree with the include placed correctly (right after find_package(Python3)), this PR's checker fails at CMakeLists.txt:175 while #2072's passes — because FIND matched the raw text and INCLUDE the comment-stripped text, so a comment mentioning find_package above the real call moved the boundary. The arm here passes only because both synthetic trees have no such comment above the call. #2072 contains this branch (--is-ancestor → YES): land it and close this one.

[bong-water-water-bong]

VERDICT at 10a08b5: READY, and the risk it names is the exact failure mode of every guard tonight

The observation is a first-class one and it is stated as a consequence, not a concern: #1981 moves the add_python_test() rows into cmake/tests-python-tools.cmake, included from CMakeLists.txt — so the ordering rule that #1864 paid for (every ${Python3_EXECUTABLE} use follows find_package(Python3)) stops covering those rows the moment they leave CMakeLists.txt, because the checker reads one file and its content moved to another.

That is the "the guard stops covering what it used to cover" failure, and it is tonight's dominant pattern in a new form: #1912's detector that could not see a spelling, #2023's sweep that missed tests/*.py, #1981's family file that only one guard understood, and #1983's glob that a literal-include() checker would miss. Four PRs, one shape: a check whose scope is a file, a path, or a spelling, while the thing it checks keeps moving.

Two asks, in order:

1. Resolve includes rather than special-casing this one file. ci_targets_check.py already follows include() (since ci: ci_targets_check gains direction B - a ratchet on tests whose targets CI never builds (#1595) #1601), so the mechanism exists — the ordering check should do the same, or the rule will break again the next time a family moves. A check that hardcodes cmake/tests-python-tools.cmake fixes today and not the class.
2. State the ordering across the include boundary explicitly: the include must appear after find_package(Python3) and after add_python_test()'s definition (I raised that on cmake: the Python tool self-tests get their own registration file (engine#1979, first family) #1981). Two preconditions on one line is the sort of thing that gets violated by a rebase, so a check that verifies both — "every file containing ${Python3_EXECUTABLE} uses is included after the find_package, and the macro is defined before it is included" — is what keeps cmake: the 9 Python add_tests above find_package(Python3) get an empty ${Python3_EXECUTABLE}, so they run only through their exec bit #1864's paid-for lesson paid for.

And a positive note on the shape: putting the ordering rule in its own test file (tests/python_test_order_check.py) that is itself registered means the rule is subject to the same treatment it enforces. That is the right recursion, and it is exactly what #1912's self-test was praised for.

One question worth answering in the body, since it decides whether the rule is complete: does the checker also follow the glob from #1983 once it lands? If rows can arrive via cmake/tests-*.cmake matched by a glob rather than an include(), a rule that follows include() is still one mechanism behind. Closing all three (#1981 include, #1983 glob, this resolver) together is the only state where "every use follows the find_package" is actually true of the tree.

[bong-water-water-bong]

Contained in #2123 — git merge-base --is-ancestor says this branch is an ancestor of #2123's head (3be7aed), which is this PR plus +41/−5 (per-include-tree line attribution, and an arm asserting a comment above a wrong order does not steal the reported line).

So the pair should land as one: #2123 is the superset, and merging this first would conflict with its own extension in the same file (tests/python_test_order_check.py). Recommend closing this in favour of #2123 — unless there is something in this branch's shape you want kept that the extension dropped, in which case say which hunk.

For the record on #1979: #1981 (CMakeLists.txt + cmake/tests-python-tools.cmake) is a different answer to the same issue — it moves the rows out of the contended file instead of checking the order afterwards. The two are complementary; only this pair is a duplicate.