CNA-BUG-198: Link-closure tests pass --build-dir ${CMAKE_BINARY_DIR}, so when CNA is added as a subproject of a Makefiles build they look for link.txt in the consumer's build root and always skip

CNA snapshot c1c316b9  ·  Known Issues › Current bugs  ·  source links pinned to c1c316b9

The probe targets are defined in CNA's own root directory, whose binary directory is a subdirectory of the consumer's build tree; under a Makefiles generator the checker is pointed at the top-level build root instead and never finds CMakeFiles/<probe>.dir/link.txt (Ninja trees are now read through ninja and are unaffected).

Identifier

CNA-BUG-198

Category

Bug

Subsystem

Build & CI

Status

Narrowed (partially fixed; describes only what survives)

Verified against

CNA c1c316b9 (c1c316b9c7a846ce8002809c151fcd1af14942c9)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

None

Affected contract

cmake/Tests/ModuleProbes.cmake ModuleLinkClosure_* --build-dir argument

Expected behaviour

A gate registered by CNA should evaluate the same way whether CNA is the top-level project or consumed with add_subdirectory (a consumer shape CNA supports; see the CNA_SOURCE_DIR comment in CMakeLists.txt).

Actual behaviour at TARGET

Every add_test(NAME ModuleLinkClosure_... --build-dir "${CMAKE_BINARY_DIR}" ...) in ModuleProbes.cmake uses the top-level binary directory. The probes are created by the include(cmake/Tests/ModuleProbes.cmake) in CNA's root CMakeLists.txt, so their CMakeFiles/<probe>.dir/link.txt lives under CMAKE_CURRENT_BINARY_DIR. In a subproject build the two differ, and under a Makefiles generator every closure gate returns 77 (SKIP).

Fixed since first recorded: check_module_link_closure.py now reads a Ninja tree's link line with ninja -C <build-dir> -t commands -s <target> (ninja_link_line, AM4-167), taking the generator and the ninja program from <build-dir>/CMakeCache.txt. In a subproject the consumer's build root holds the tree's only build.ninja and CMakeCache.txt, so a Ninja build measures the gates correctly; only the Makefiles generator's link.txt lookup still points at the wrong directory.

Source locations

• cmake/Tests/ModuleProbes.cmake — --build-dir ${CMAKE_BINARY_DIR} in every link-closure registration
• CMakeLists.txt — include(cmake/Tests/ModuleProbes.cmake) in CNA's root directory
• scripts/check_module_link_closure.py — main looks for <build-dir>/CMakeFiles/<target>.dir/link.txt; ninja_link_line reads a Ninja tree through ninja -t commands (the narrowed half)

Evidence

Checked by reading the named sources at c1c316b9; nothing was built or executed for this entry. The failure mode is a silent SKIP, not a false pass or fail.

Re-verified at c1c316b9: read cna_add_module_probe in ModuleProbes.cmake (still --build-dir "${CMAKE_BINARY_DIR}") and check_module_link_closure.py after AM4-167 (12ab7471b). That the Ninja path also works for a subproject follows from CMake's Ninja generator writing every target name as a top-level alias in the one build.ninja; no subproject build was run.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

None; no configuration tests CNA as a subproject with tests on.

Regression test

Pass ${CMAKE_CURRENT_BINARY_DIR} (or the probe target's BINARY_DIR property) and add a subproject fixture that runs one closure gate.

Blast radius

Consumers that embed CNA with CNA_BUILD_TESTS=ON and build with a Makefiles generator; top-level builds and Ninja builds are unaffected.

Workaround

Run the closure gates from a top-level CNA build.