Repository navigation
ITK_INSTALL_*_DIR are assumed relative to CMAKE_INSTALL_PREFIX; absolute values yield wrong paths #6896
Description
ITK_INSTALL_RUNTIME_DIR and ITK_INSTALL_LIBRARY_DIR are joined to CMAKE_INSTALL_PREFIX in several places, so an absolute value silently yields a malformed path. CMake installs an absolute DESTINATION outside the prefix, so the two disagree.
Where the assumption is made
| Site | Expression |
|---|---|
CMake/ITKModuleMacros.cmake:533 |
"\${ITK_INSTALL_PREFIX}/${ITK_INSTALL_RUNTIME_DIR}" |
CMake/ITKModuleMacros.cmake:542 |
"\${ITK_INSTALL_PREFIX}/${ITK_INSTALL_LIBRARY_DIR}" |
Modules/Core/TestKernel/src/CMakeLists.txt |
the installed itkTestDriver RPATH |
The first two feed <module>_RUNTIME_LIBRARY_DIRS in the exported configuration, so a consumer of an installed ITK inherits the wrong directories, not just the test driver.
Defaults are relative (bin, and ${CMAKE_INSTALL_LIBDIR} which defaults to lib), so the supported configurations are unaffected.
What support would require
Each site needs to branch on IS_ABSOLUTE and skip the prefix join, and the exported ITKConfig would need the same treatment so that relocation logic does not rewrite a deliberately absolute path. That is a repo-wide change to the module macros and the exported configuration, which is why it is filed separately rather than folded into a single install rule.
A narrower alternative is to state in the documentation that these variables must be relative and keep the configure-time guards.
Found by an automated review on PR #6894, which added the itkTestDriver install RPATH. That PR guards its own computation with IS_ABSOLUTE and fails at configure time rather than emitting a wrong RPATH; the other two sites are unguarded.
Activity
hjmjohnson commentedon Sep 23, 2026
Concrete measurement of the breakage, from PR #6894.
Configuring
mainwith-DCMAKE_INSTALL_LIBDIR=/usr/lib64(whichGNUInstallDirspermits) exits 0, but the exported configuration is wrong:That is
CMake/ITKModuleMacros.cmake:542joining the build directory to an already-absolute path, with the doubled slash, pointing where no library is installed. CMake also writes the generated package files into<build-dir>/usr/lib64/.So the layout is silently wrong rather than unsupported-but-working, which raises the priority of picking a policy here: either handle absolute values at every site, or reject them once, centrally, where the variables are defined.
PR #6894 now aborts at configure time when it sees an absolute value, but only from
Modules/Core/TestKernel/src/CMakeLists.txt, which is a narrow and slightly arbitrary place for a global constraint to be enforced. A check next to the defaults inCMakeLists.txt:224-236would be the better home once this is decided.dzenanz commentedon Sep 23, 2026
Enforcing that
ITK_INSTALL_*_DIRs are relative sounds like the right thing to do.