Install the cmake files to lib/cmake/<PACKAGE_NAME>

[jmcarcell]

BEGINRELEASENOTES

• Install the cmake files to lib/cmake/<PACKAGE_NAME>

ENDRELEASENOTES

Currently how it works is that the Config.cmake files from packages that use iLCUtil are installed to the top directory. For LCGCMake views, the files in the top level directory do not belong in the view, and while building the stack works fine, building any package that needs to find these Config.cmake files won't work.

I propose to install them to lib/cmake (using GNUInstallDirs does not work since all the packages that are using the macro would need to have that included and that is not the case right now). This is how the installation folder ends up looking like:

/ilcutil/01.07.03/x86_64-el9-gcc14-opt/lib/cmake/ILCSOFT_CMAKE_MODULES:
total 16K
drwxr-xr-x. 2 sftnight sf 4.0K Feb  2 16:12 .
drwxr-xr-x. 6 sftnight sf 4.0K Feb  2 16:12 ..
-rw-r--r--. 1 sftnight sf 1.6K Feb  2 16:12 ILCSOFT_CMAKE_MODULESConfig.cmake
-rw-r--r--. 1 sftnight sf  581 Feb  2 16:12 ILCSOFT_CMAKE_MODULESConfigVersion.cmake

/ilcutil/01.07.03/x86_64-el9-gcc14-opt/lib/cmake/ILCTEST:
total 16K
drwxr-xr-x. 2 sftnight sf 4.0K Feb  2 16:12 .
drwxr-xr-x. 6 sftnight sf 4.0K Feb  2 16:12 ..
-rw-r--r--. 1 sftnight sf 1.7K Feb  2 16:12 ILCTESTConfig.cmake
-rw-r--r--. 1 sftnight sf  604 Feb  2 16:12 ILCTESTConfigVersion.cmake

/ilcutil/01.07.03/x86_64-el9-gcc14-opt/lib/cmake/ILCUTIL:
total 16K
drwxr-xr-x. 2 sftnight sf 4.0K Feb  2 16:12 .
drwxr-xr-x. 6 sftnight sf 4.0K Feb  2 16:12 ..
-rw-r--r--. 1 sftnight sf 2.1K Feb  2 16:12 ILCUTILConfig.cmake
-rw-r--r--. 1 sftnight sf  577 Feb  2 16:12 ILCUTILConfigVersion.cmake

/ilcutil/01.07.03/x86_64-el9-gcc14-opt/lib/cmake/streamlog:
total 16K
drwxr-xr-x. 2 sftnight sf 4.0K Feb  2 16:12 .
drwxr-xr-x. 6 sftnight sf 4.0K Feb  2 16:12 ..
-rw-r--r--. 1 sftnight sf 1.9K Feb  2 16:12 streamlogConfig.cmake
-rw-r--r--. 1 sftnight sf 3.2K Feb  2 16:12 streamlogConfigVersion.cmake

Packages that were already looking for the Config.cmake file in the top level folder will still find it because they also look in lib/cmake/<PACKAGE_NAME> (*with one exception below). In addition, leaving the Deps.cmake file under lib/cmake means no paths need to be changed in all those packages that hardcode it, see for example https://github.com/iLCSoft/CED/blob/8bcaae8d2c7f4800710d64a0613a1b4555aba6e1/cmake/CEDConfig.cmake.in#L57 or https://github.com/iLCSoft/KalDet/blob/a667b1799f185e3ed201eaec5d40ce9e685d95e5/cmake/KalDetConfig.cmake.in#L61.

*The exception is RAIDA. Many packages use find_package(AIDA), which means they look for the Config.cmake files under lib/cmake/AIDA which wouldn't be there unless the installation is changed. In addition, AIDAConfig.cmake hardcodes finding RAIDAConfig.cmake to some location which would stop working (see https://github.com/iLCSoft/RAIDA/blob/master/cmake/AIDAConfig.cmake.in#L6), so a change would be needed.

In summary: This PR, together with one in RAIDA and a change in the installation instructions for RAIDA (for example in the spack recipe), make it possible to make stacks based on views on LCGCMake (probably any view-based stack) work.

[tmadlener]

In summary: This PR, together with one in RAIDA and a change in the installation instructions for RAIDA (for example in the spack recipe), make it possible to make stacks based on views on LCGCMake (probably any view-based stack) work.

From an organization point of view: Can this one be merged without the PR in RAIDA or do they have to go in at the same time?

[tmadlener]

Just found out while trying this out: RAIDA has to go first.

[tmadlener]

closing and opening again to re-trigger the previously disabled key4hep workflows

[jmcarcell]

iLCSoft/RAIDA#10 is harmless so let's go ahead with this one and we'll see tomorrow...

[jmcarcell]

Builds went fine and are deployed now, it seems everything is working in the Key4hep stack (Spack) at least.