ITK_INSTALL_*_DIR are assumed relative to CMAKE_INSTALL_PREFIX; absolute values yield wrong paths

[hjmjohnson]

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.

[hjmjohnson]

Concrete measurement of the breakage, from PR #6894.

Configuring main with -DCMAKE_INSTALL_LIBDIR=/usr/lib64 (which GNUInstallDirs permits) exits 0, but the exported configuration is wrong:

ITKCommon_RUNTIME_LIBRARY_DIRS = "<build-dir>//usr/lib64"

That is CMake/ITKModuleMacros.cmake:542 joining 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 in CMakeLists.txt:224-236 would be the better home once this is decided.

[dzenanz]

Enforcing that ITK_INSTALL_*_DIRs are relative sounds like the right thing to do.