COMP: Improve ITKVtkGlue build robustness on Windows and with unusable VTK - #6848
Conversation
|
A VTK without Python wrapping, or a static VTK whose wrapping collapses into a single _vtkmodules_static module, is only detected when the Python tests run and fail to import. Check both while configuring and name the remedy. VTK exports no shared/static variable, so the imported VTK::CommonCore target is queried directly.
Windows has no RPATH, so the test executables abort with STATUS_DLL_NOT_FOUND before reaching main, which ctest reports only as an opaque exit code. The Python tests are unaffected because itkTestDriver already sets their environment. ENVIRONMENT_MODIFICATION is a no-op on other platforms.
b221937 to
29dd4df
Compare
|
My home computer build now errors out during configure stage: |
|
This maybe hasn't gone enough. The DLL is still not found. But a different one? |
|
I did clean build of VTK with shared libraries, and I still run into test failures: Looking at the test command line, I don't think that VTK binary dir is added to PATH. |
Two build-robustness fixes for
ITKVtkGlue, both from independent Windows validation of #6715 (now merged). Each replaces a failure that surfaces late and cryptically with one that names its remedy.ImportErrorwhen the Python tests run.PATH, instead of aborting withSTATUS_DLL_NOT_FOUNDbefore reachingmain.1. Reject unusable VTK configurations at configure time
Two VTK shapes were only detected when the Python tests ran:
VTK_WRAP_PYTHON— not caught until an import fails._vtkmodules_staticmodule, and the tests die withImportError: DLL load failed while importing _vtkmodules_static.A shared VTK produces per-module extensions and works.
Both are now checked while configuring, with the remedy named in the message.
VTK exports no shared/static variable —
VTK_BUILD_SHARED_LIBSis not part of its package — so the importedVTK::CommonCoretarget is queried for itsTYPEinstead. An earlier attempt using the variable produced a false positive on a perfectly good shared VTK, since the undefined variable read as false.2. VTK's DLL directory on PATH for the Windows tests
Windows has no RPATH, so the VtkGlue C++ test executables abort with
0xc0000135(STATUS_DLL_NOT_FOUND) before reachingmain. ctest reportsonly an opaque exit code.
The failure is especially misleading because the Python tests pass in the
same run —
itkTestDriveralready sets their environment with--add-before-libpath. So it presents as "C++ broken, Python fine", whichreads like a code defect rather than an environment gap.
ENVIRONMENT_MODIFICATIONwithpath_list_prependis applied to every testregistered in the directory, via
get_property(DIRECTORY PROPERTY TESTS), sothe conditional rendering tests are covered too. It is
WIN32-guarded and ano-op elsewhere.
ENVIRONMENT_MODIFICATIONrequires CMake 3.22, and ITK'sITK_OLDEST_VALIDATED_POLICIES_VERSIONis 3.22.1, so no version gate isneeded.
Verification
macOS arm64 against a purpose-built VTK 9.6.2 (non-kit, rendering, Python
wrapped for the same interpreter as ITK):
ITK_USE_PYTHON_LIMITED_API=OFFand=ON.pre-commit run --all-filesexits 0.The
VTK_WRAP_PYTHONcheck is confirmed to read VTK's real exported valuerather than an empty one: it does not fire on a wrapped VTK, and an undefined
variable would have fired.
The Windows path is not exercised by this verification — the change is
WIN32-guarded and was authored from a Windows report, so it needs a WindowsCI run or a manual check to confirm.
Related findings, deliberately not in this PR
The same Windows validation surfaced three issues that are ITK-wide rather
than VtkGlue-specific, and belong in their own changes:
Module_ITKTestKernelfails silently without:BOOL. WithITK_BUILD_DEFAULT_MODULES=OFF,-DModule_ITKTestKernel=ONleavesINTERNAL=OFF; the dependent C++ tests are never created and ctest reports100% pass on what remains.
here shows
Labels: ITKFFTImageFilterInit Python.itk_python_add_testdelegates to
itk_add_test, which labels with${itk-module}, and thatvariable is stale in the
Wrapping/Modules/<Name>/testscope. The effect isthat
ctest -L ITKVtkGlueandctest -R "VtkGlue|ImageToVTK|VTKImageTo"select different sets that both happen to contain 8 tests, which hides the
discrepancy.
ITK_USE_PYTHON_LIMITED_APIvalue is never printed, thoughit auto-enables by interpreter version.
Also related and already filed: #6846, ITKVtkGlue cannot configure against a
rendering-free VTK because the
VTK_RENDERING_BACKENDguard tests a VTK 8variable that VTK 9 never defines.