Install the cmake files to lib/cmake/<PACKAGE_NAME> #36
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tmadlener
force-pushed
the
cmake-installation
branch
from
8fc9ad3 to
54d0f51
Compare
Contributor
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? |
Contributor
|
Just found out while trying this out: RAIDA has to go first. |
jmcarcell
added a commit
to jmcarcell/RAIDA
that referenced
this pull request
Jan 18, 2026
before the root installation folder. This change works with the existing version of iLCUtil and also with a future change where the Config files are installed to lib/cmake instead of the root of the installation folder. See iLCSoft/iLCUtil#36
tmadlener
pushed a commit
to jmcarcell/RAIDA
that referenced
this pull request
Jan 19, 2026
before the root installation folder. This change works with the existing version of iLCUtil and also with a future change where the Config files are installed to lib/cmake instead of the root of the installation folder. See iLCSoft/iLCUtil#36
tmadlener
pushed a commit
to iLCSoft/RAIDA
that referenced
this pull request
Jan 19, 2026
before the root installation folder. This change works with the existing version of iLCUtil and also with a future change where the Config files are installed to lib/cmake instead of the root of the installation folder. See iLCSoft/iLCUtil#36
jmcarcell
force-pushed
the
cmake-installation
branch
from
54d0f51 to
4379230
Compare
Contributor
|
closing and opening again to re-trigger the previously disabled key4hep workflows |
tmadlener
approved these changes
Jan 20, 2026
Contributor
Author
|
iLCSoft/RAIDA#10 is harmless so let's go ahead with this one and we'll see tomorrow... |
Contributor
Author
|
Builds went fine and are deployed now, it seems everything is working in the Key4hep stack (Spack) at least. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BEGINRELEASENOTES
ENDRELEASENOTES
Currently how it works is that the
Config.cmakefiles 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 theseConfig.cmakefiles won't work.I propose to install them to
lib/cmake(usingGNUInstallDirsdoes 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:Packages that were already looking for the
Config.cmakefile in the top level folder will still find it because they also look inlib/cmake/<PACKAGE_NAME>(*with one exception below). In addition, leaving theDeps.cmakefile underlib/cmakemeans 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 theConfig.cmakefiles underlib/cmake/AIDAwhich wouldn't be there unless the installation is changed. In addition,AIDAConfig.cmakehardcodes findingRAIDAConfig.cmaketo 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.