test: stop compile-fail tests racing on the shared build tree

Each compile-fail test runs `cmake --build` on the shared build tree as
its test command. When that tree is out of date - someone edited a
CMakeLists.txt - all 24 of them re-run CMake at once under `ctest -j N`
and corrupt each other's regeneration. On Ninja the losers die with

    ninja: error: failed recompaction: No such file or directory
    FAILED: build.ninja

before compiling anything, so the expected diagnostic never reaches the
output and PASS_REGULAR_EXPRESSION fails. It reproduces in roughly two
runs out of three with

    touch test/CMakeLists.txt; ctest -R compile_fail -j32

and not at all on an up-to-date tree, which is why it looked random.
644c3e2 predicted this ("other generators race analogously on the
cmake-regeneration step") but 0b0e7db narrowed the RESOURCE_LOCK to the
Visual Studio generator, leaving Ninja exposed.

Do the regeneration once, in a CTest fixture, so no test regenerates
while another runs. That keeps the 24 compiles parallel, unlike a lock.
10/10 stale-tree runs at -j32 are now clean.

The Visual Studio lock stays, and its comment was wrong: the race there
is not the regeneration step, so the fixture does not help. Every MSBuild
invocation walks the whole project dependency graph and rewrites the
.tlog/.lastbuildstate of each project it passes through, the dependencies'
as well as ZERO_CHECK's, so concurrent invocations collide whether or not
anything needs regenerating. Measured with VS 18 2026: 7-13 of 24 fail on
every run without the lock, 3/3 clean with it. Windows users who want
these parallel should configure with -G Ninja, which is clean at -j32 and
~14x faster.

b2 is unaffected: it compiles these sources as ordinary targets in its own
dependency graph rather than shelling out to a nested build. ~40 runs at
-j32/-j64/-j128 found nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: jll63

CLAUDE.md

@@ -99,6 +99,28 @@ comment above the marker - `no matching` (clang/gcc "no matching function for ca
 matching overloaded function found"), `deleted function` (gcc "use of a", clang "call to", MSVC
 "attempting to reference a").
 
+**Do not let the compile-fail tests regenerate the build tree concurrently.** Each one runs
+`cmake --build` on the shared tree as its test command, so when the tree is stale they all re-run
+CMake at once and corrupt each other - on Ninja the losers die with `failed recompaction` /
+`FAILED: build.ninja` before compiling anything, the expected diagnostic never appears, and the
+test fails. It reproduces about two runs in three with `touch test/CMakeLists.txt; ctest -R
+compile_fail -j32`, and not at all on an up-to-date tree, which is why it reads as random. The
+empty `boost_openmethod-compile_fail_fixture` target plus `FIXTURES_SETUP`/`FIXTURES_REQUIRED`
+does the regeneration once, before any of them.
+
+**The Visual Studio `RESOURCE_LOCK` is still needed on top - do not remove it.** MSBuild is not
+fixable by the fixture: every one of the 24 concurrent invocations walks the same project
+dependency graph and stomps the same `.tlog`/`.lastbuildstate` files, not just `ZERO_CHECK`'s.
+Measured with VS 18 2026 + `ctest -R compile_fail -j32`: without the lock, 7-13 of 24 fail on
+*every* run; with it, 3/3 clean at 24s (serialized). The lock is scoped to the generator, so
+**Windows already runs these fully parallel under `-G Ninja`** - 4/4 clean, 1.65s, same
+`cl.exe`. That is the fast path on Windows; the generator cannot be defaulted from CMakeLists.txt
+anyway (it is fixed before the file is read - only a preset or `CMAKE_GENERATOR` in the
+environment can set it), and CI picks its own.
+
+b2 is not affected - it compiles these sources as ordinary targets in its own dependency graph
+instead of shelling out to a nested build (~40 runs at `-j32`/`-j64`/`-j128` are clean).
+
 **b2 cannot check the message - do not try to make it.** `test/Jamfile` already loops
 (`compile-fail $(src)`), but Boost.Build's `compile-fail` only inverts the exit status: the
 `expect-failure-generator` sets `T_FLAG_FAIL_EXPECTED` and the engine flips OK/FAIL

test/CMakeLists.txt

@@ -108,6 +108,31 @@ target_link_libraries(boost_openmethod-test_mix_release_debug PRIVATE Boost::ope
 boost_openmethod_add_test(boost_openmethod-test_mix_release_debug)
 add_dependencies(tests boost_openmethod-test_mix_release_debug)
 
+# Every compile-fail test runs `cmake --build` on the shared build tree. When
+# that tree is out of date - someone edited a CMakeLists.txt - each of them
+# re-runs CMake, and under `ctest -j N` those regenerations run concurrently and
+# corrupt each other. On Ninja the losers die with
+#
+#     ninja: error: failed recompaction: No such file or directory
+#     FAILED: build.ninja
+#
+# before compiling anything, so the expected diagnostic never appears and the
+# test fails - reproducibly, in roughly two runs out of three. (Unix Makefiles
+# survived the same stress, but the window is not specific to Ninja, so close it
+# for every generator.) Bring the tree up to date once, in a CTest fixture, so
+# no test regenerates while another is running. The target is empty: building it
+# does nothing except make the generator refresh its build files first. CTest
+# pulls a required fixture's setup test in automatically, so a narrower
+# `ctest -R ...` selection still gets it.
+add_custom_target(boost_openmethod-compile_fail_fixture)
+add_test(
+    NAME boost_openmethod-compile_fail_fixture
+    COMMAND "${CMAKE_COMMAND}" --build ${CMAKE_BINARY_DIR}
+            --target boost_openmethod-compile_fail_fixture --config $<CONFIG>)
+set_property(
+    TEST boost_openmethod-compile_fail_fixture
+    PROPERTY FIXTURES_SETUP openmethod_build_tree)
+
 function(openmethod_compile_fail_test testname fail_regex)
     set(test_target "boost_openmethod-${testname}")
     add_library(${test_target} STATIC EXCLUDE_FROM_ALL "${testname}.cpp")
@@ -116,15 +141,19 @@ function(openmethod_compile_fail_test testname fail_regex)
         NAME "${test_target}"
         COMMAND "${CMAKE_COMMAND}" --build ${CMAKE_BINARY_DIR} --target "${test_target}" --config $<CONFIG>)
     set_property(TEST "${test_target}" PROPERTY PASS_REGULAR_EXPRESSION "${fail_regex}")
-    # Each of these tests runs `cmake --build` on the shared build tree. With
-    # the Visual Studio generator, concurrent MSBuild invocations race on shared
-    # files (every MSBuild invocation rewrites ZERO_CHECK.tlog/
-    # ZERO_CHECK.lastbuildstate, and the losers abort with MSB3491 before
-    # compiling anything, so the expected diagnostic never appears in the
-    # output). Serialize the compile-fail tests among themselves in that case;
+    set_property(TEST "${test_target}" PROPERTY FIXTURES_REQUIRED openmethod_build_tree)
+    # The fixture above is enough for Ninja and Makefiles, but not for the
+    # Visual Studio generator, where the regeneration step is not the problem:
+    # every MSBuild invocation walks the whole project dependency graph and
+    # rewrites the .tlog/.lastbuildstate of each project it passes through -
+    # ZERO_CHECK's and the dependencies' alike - so concurrent invocations
+    # collide whether or not anything needs regenerating, and the losers abort
+    # (MSB3374/3375/3491/3501) before compiling anything. Measured with VS 18
+    # 2026 at `ctest -R compile_fail -j32`: 7-13 of 24 fail on every run without
+    # the lock, 3/3 runs clean with it. Serialize them among themselves there;
     # they still run in parallel with the ordinary tests, which do not touch the
-    # build tree. Other generators (Ninja, Makefiles) tolerate concurrent
-    # `cmake --build` invocations, so leave those free to run in parallel.
+    # build tree. Windows users who want these parallel should configure with
+    # -G Ninja, which is clean and ~14x faster here.
     if (CMAKE_GENERATOR MATCHES "Visual Studio")
         set_property(TEST "${test_target}" PROPERTY RESOURCE_LOCK openmethod_compile_fail)
     endif()