COMP: Declare ITKGoogleTest where GTest drivers are built

[hjmjohnson]

Seven modules call CreateGoogleTestDriver without declaring ITKGoogleTest in TEST_DEPENDS, so enabling one of them alone with BUILD_TESTING=ON fails on an unresolved GTest::gtest. Second commit adds a guard in CreateGoogleTestDriver that names the missing declaration.

Why the guard is second, and evidence it detects the defect

The guard was written first and the declarations second. That order is a red/green pair but leaves commit 1 unbuildable — with the guard applied to unpatched main, both a default and a minimal configure fail:

CMake Error at CMake/ITKModuleTest.cmake:320 (message):
  ITKCurvatureFlow builds a GoogleTest driver: add ITKGoogleTest to its
  TEST_DEPENDS

CMake Error at CMake/ITKModuleTest.cmake:320 (message):
  ITKIONRRD builds a GoogleTest driver: add ITKGoogleTest to its TEST_DEPENDS

Reordered so every commit configures; the tree at the tip is byte-identical to the tree that produced those runs. The guard therefore detects exactly the seven declarations that the first commit adds.

Symptom without the guard

$ cmake -DITK_BUILD_DEFAULT_MODULES=OFF -DModule_ITKIONRRD=ON -DBUILD_TESTING=ON ...
CMake Error at CMake/ITKModuleTest.cmake:320 (target_link_libraries):
  Target "ITKIONRRDGTestDriver" links to:
    GTest::gtest
  but the target was not found.
Call Stack (most recent call first):
  Modules/IO/NRRD/test/CMakeLists.txt:425 (creategoogletestdriver)

TEST_DEPENDS carries two effects here: ITK_MODULE_<mod>-Test_DEPENDS enables ITKGoogleTest, and itk_module_test() puts ITK::ITKGoogleTestModule on the test kit's interface.

The guard keys on ${itk-module}, not the KIT argument: five call sites pass a KIT that differs from the module name (Registration/Common, ImageFrequency, BoneEnhancement, SuperPixel, IO/GDCM), and a KIT-keyed check reports ITKIOGDCM as an offender when it is not one.

Local validation

macOS arm64, -DBUILD_TESTING=ON:

tree	default modules	-DModule_ITKIONRRD=ON only
main	configures	fails on GTest::gtest
guard applied to main	fails, names ITKCurvatureFlow	fails, names ITKIONRRD
first commit	configures	configures
both commits	configures	configures

Minimal tree at the tip: build ok, ctest 100% tests passed out of 230. pre-commit run --all-files clean.

AI assistance

• Role: detection sweep across the 72 modules that build GTest drivers, guard implementation, red/green runs
• Evidence of local testing: table above

[greptile-apps]

Greptile Summary

Adds explicit ITKGoogleTest test dependencies for the modules that create GoogleTest drivers, and adds a configuration-time check that reports missing declarations using the owning module name.

Confidence Score: 5/5

No blocking failure remains.

No blocking failure remains.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for the posted P1 finding.
• Contract validation disproved that ITKGoogleTest was missing from TEST_DEPENDS after the patch.
• Contract validation verified that multiple ITK module cmake files now declare ITKGoogleTest, including the listed modules.
• Runtime validation is blocked because the pixi command is not found, so CreateGoogleTestDriver could not be executed by CMake.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Runtime CMake validation is blocked by a missing Pixi executable

   • Bug
     • The repository-prescribed command for the narrow ITKIONRRD configuration could not run: /bin/sh: pixi: not found (exit 127). The runtime valid-declaration and disposable missing-declaration failure paths consequently remain unexecuted.
   • Cause
     • pixi is not installed or exposed on PATH in the supplied environment; cmake, ctest, and ninja are likewise unavailable outside the Pixi environment.
   • Fix
     • Provision Pixi, then run the captured script with HEAD and a disposable tree with one ITKGoogleTest declaration removed using the locked cxx environment.

   _{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "COMP: Require ITKGoogleTest in TEST_DEPE..." | Re-trigger Greptile}

[blowekamp]

My responses have been short and off the cuff to try to quickly address PRs and lengthly comment. I am assuming these PR are not taking much time, and are mostly AI drive. This PR is OK, however...

I looked at this a bit closer and considered the transitive dependencies.

I see that ITKTestKernel has ITKGoogleTest as TEST_DEPENDS - that specification would NOT be transitive at all even for the uses in consuming module's TEST_DEPENDS. Perhaps changing ITKTestKernel's ITKGoogleTest dependency to PUBLIC every modules would transitively get the GTest dependency linked as initially desired in the prior PR. Given that ITKTestKernel has GTest include in its header, this would seem to be consistent.

[blowekamp]

My responses have been short and off the cuff to try to quickly address PRs and lengthly comment. I am assuming these PR are not taking much time, and are mostly AI drive. This PR is OK, however...

I looked at this a bit closer and considered the transitive dependencies.

I see that ITKTestKernel has ITKGoogleTest as TEST_DEPENDS - that specification would NOT be transitive at all even for the uses in consuming module's TEST_DEPENDS. Perhaps changing ITKTestKernel's ITKGoogleTest dependency to PUBLIC every modules would transitively get the GTest dependency linked as initially desired in the prior PR. Given that ITKTestKernel has GTest include in its header, this would seem to be consistent.

Wait.... I made another comment today that the "GTest" third party library was not installed. The change above would create a problem with an installed ITKTestKernel not having one of its dependencies available.

These GTest issues are like an onion 🧅, they have many layers.

[hjmjohnson]

Closing in favour of #6781, which carries the details.

@blowekamp both of your points hold. TEST_DEPENDS does not export at all — the installed module file has _DEPENDS, _PUBLIC_DEPENDS, _TRANSITIVE_DEPENDS and _PRIVATE_DEPENDS, and no _TEST_DEPENDS, so ITKTestKernel's GoogleTest declaration conveys nothing to a consumer. And your walk-back is right: promoting it to public is blocked by the install story, and harder than "one dependency unavailable" — itk_module_load ends in message(FATAL_ERROR "No such module"), so in a BUILD_TESTING=OFF install every consumer of ITKTestKernel would fail outright.

One more layer while checking that: an installed ITK ships itkGTest.h, itkGTestPredicate.h and itkGTestTypedefsAndConstructors.h, all of which #include "gtest/gtest.h", while installing neither the gtest headers nor any GTest:: target. grep -c 'GTest::' on the installed ITKTargets.cmake is 0 against 14 in the build tree. Downstream cannot include those public headers from an installed ITK.

The scope has moved from an easy fix for a very rare corner case to a complicated problem: it now depends on whether an installed ITK is meant to support GoogleTest-based downstream tests, and that answer decides whether the installed itkGTest*.h headers are the defect or the export is. Better to leave this closed until there is time and resources to address it thoroughly than to land a partial fix that makes the next layer harder to see.

The branch stays on my fork if the guard is wanted later; it was verified red/green with 230/230 ctest.

[blowekamp]

@hjmjohnson Will all that being said this PR is still OK. It does not introduce any new issues with dependencies or installation. It does manually IMPROVE the dependencies of these modules. It however does not make it easier for other test modules to implicitly get the gtest dependency, and that is OK.

[hjmjohnson]

@blowekamp Thanks. I misunderstood. I just don't want this issue to be a distraction from the more important work you are doing. I was afraid it was becoming an unnecessary burden until we have more resources (fingers crossed that we can get some grant support soon).