ITKInternalEigen3 not installed when using CMake 3.28.0 | 3.28.1 downloaded from CMake releases (reproduced in Windows)

[kislinsk]

Build and install ITK in any configuration but make sure not to use an external/system Eigen dependency.

When any project tries to find the installed ITK, for example with find_package(ITK 5.4 REQUIRED), a CMake error occurs:

CMake Error at D:/ITK-install/lib/cmake/ITK-5.4/Modules/ITKEigen3.cmake:16 (find_package):
  Could not find a package configuration file provided by "ITKInternalEigen3"
  (requested version 3.3) with any of the following names:

    ITKInternalEigen3Config.cmake
    itkinternaleigen3-config.cmake

  Add the installation prefix of "ITKInternalEigen3" to CMAKE_PREFIX_PATH or
  set "ITKInternalEigen3_DIR" to a directory containing one of the above
  files.  If "ITKInternalEigen3" provides a separate development package or
  SDK, be sure it has been installed.
Call Stack (most recent call first):
  D:/ITK-install/lib/cmake/ITK-5.4/ITKModuleAPI.cmake:86 (include)
  D:/ITK-install/lib/cmake/ITK-5.4/ITKModuleAPI.cmake:31 (itk_module_load)
  D:/ITK-install/lib/cmake/ITK-5.4/ITKModuleAPI.cmake:143 (_itk_module_config_recurse)
  D:/ITK-install/lib/cmake/ITK-5.4/ITKConfig.cmake:88 (itk_module_config)
  CMakeLists.txt:5 (find_package)

The <INSTALL_DIR>/lib/cmake/ITK-5.4/Modules directory contains an ITKEigen3.cmake file, with the following content at the end:

set(ITK_USE_SYSTEM_EIGEN "OFF")
set(ITKInternalEigen3_DIR "${ITK_MODULES_DIR}")
find_package(ITKInternalEigen3 3.3 REQUIRED CONFIG)

However, ITKInternalEigen3 is not installed by ITK and only present in the build directory.

[kislinsk]

We have this issue in MITK and it was reported by users multiple times already until we noticed it ourselves. Even in a minimal scenario by building and installing "default" ITK and a demo project like the following, the error is reproducible:

cmake_minimum_required(VERSION 3.16.3...3.19.7) # Same as ITK
project(demo)
find_package(ITK 5.4 REQUIRED)

[phcerdan]

Thanks for raising this up.
I cannot reproduce it locally in Linux.

In Linux <INSTALL_DIR>/lib/cmake/ITK-5.4/Modules contains the ITKInternalEigen cmake files:

ITKInternalEigen3Config.cmake
ITKInternalEigen3ConfigVersion.cmake
ITKInternalEigen3Targets.cmake

And ITKInternalEigen3Targets.cmake points to the installed headers in <INSTALL_DIR>/include/ITK-5.4/itkeigen/Eigen/xx

Let me check in Windows, the CMake logic should be the same though.

[phcerdan]

Cannot reproduce in Windows either with master ITK, nor with v5.4rc02. All the files are there, and the demo project configures ok.

[phcerdan]

Maybe something specific to MITK?

[kislinsk]

Thanks for checking. I also reproduced it completely independent from MITK. Did you do clean builds from scratch? If it works for you with v5.4-rc02 maybe the only difference is the CMake version. I used the latest v3.28.1.

[phcerdan]

build from scratch

cmake.exe --version
3.23.2

Let me try with latest...

[phcerdan]

Ok, I can reproduce it with v3.28.1 in Windows

[kislinsk]

I tried also with CMake v3.27.9 and v3.28.0 and both work. So something broke in CMake v3.28.1 I guess. I can even use CMake v3.28.1 in my own project as long as ITK was built and installed with CMake <= v3.28.0.

[phcerdan]

Good narrowing, I will have a look tomorrow. Pinging @mathstuf in case he can help from the top of his head on the changes from 3.28.0 to 3.28.1 that broke the installation of a module (thanks!).

[phcerdan]

Nothing relevant from the diff of CMake v3.28.1 versus v3.28.0 that I can see...

[kislinsk]

Sorry I messed up my bisecting last night I guess. Had the same issue with v3.28.0 today after downgrading my installed version of CMake. I don't know what happened yesterday with the portable versions of CMake. At least I can now 100% confirm that v3.27.9 works, and starting with v3.28.0 it doesn't. Is also makes more sense that there's such a difference between two minor versions instead of patch versions.

[kislinsk]

Reading the CMake v3.28 release notes, nothing really seems to be related to this issue. Maybe the following item but that's a wild guess:

Generated files, in targets using File Sets, are now considered private by default. Generated public headers must be specified using file sets. This allows Ninja Generators to produce more efficient build graphs. See policy CMP0154.