CMake integration with external projects #916
Conversation
When calling ROOT_GENERATE_DICTIONARY in an external project after
a cmake include(${ROOT_USE_FILE}) and having installed ROOT in a
non-system location (e.g. in a home directory), the rootcling command is
missing its library path to find dynamic libraries. With the change in
this commit the correct environment for the rootcling command is set.
|
Can one of the admins verify this patch? |
|
@phsft-bot build |
|
Starting build on |
cmake/modules/RootNewMacros.cmake
Outdated
| #message(AUTHOR_WARNING "Couldn't find target: " ${library} "\n Forgot to call ROOT_GENERATE_DICTIONARY?") | ||
| endif() | ||
| add_dependencies(${library} move_headers) | ||
| if(NOT ARG_NOMOVEHEADERSDEP) |
There was a problem hiding this comment.
I think we could also check for CMAKE_PROJECT_NAME equals ROOT which means that users don't have to figure out they have to call it with this parameter. Or at least we should rename the parameter something more generic like "ROOT_EXTERNAL" because we might add more special cases for external projects here. @peremato what do you think?
There was a problem hiding this comment.
This is right. Better to check for CMAKE_PROJECT_NAME to be or not to be ROOT.
There was a problem hiding this comment.
Updated as requested.
peremato
left a comment
peremato
left a comment
There was a problem hiding this comment.
I do not understand why you have to have your FindROOT.cmake. We do provide ROOTConfig.cmake and this should be sufficient. If it is not, then this is a bug. Be as native CMake as possible and of not try to complicate things by building additional interfaces.
The functions like ROOT_LINKER_LIBRARY where intended for internal consumption. In the example provided in the howto we only use ROOT_GENERATE_DICTIONARY.
cmake/modules/RootNewMacros.cmake
Outdated
| #message(AUTHOR_WARNING "Couldn't find target: " ${library} "\n Forgot to call ROOT_GENERATE_DICTIONARY?") | ||
| endif() | ||
| add_dependencies(${library} move_headers) | ||
| if(NOT ARG_NOMOVEHEADERSDEP) |
There was a problem hiding this comment.
This is right. Better to check for CMAKE_PROJECT_NAME to be or not to be ROOT.
What we do in the
Does that mean you will not support usage in external projects? Or do you consider it now to support? If not, I suggest putting it in a different module, so its clearer which macros are meant to be for public use. |
|
Ups, logged in with wrong user, the last post was by @dennisklein |
dennisklein
force-pushed
the
external-cmake-integration
branch
2 times, most recently
from
14df1f4 to
6f918fb
Compare
If one calls the ROOT_LINKER_LIBRARY macro from an external project
after a cmake include(${ROOT_USE_FILE}), the build fails, because of the
missing move_headers target, which is defined in a ROOT project specific
CMakeLists.txt file. This commit will add the dependency to the
move_headers target only, if the macro is called from withing the ROOT
project.
dennisklein
force-pushed
the
external-cmake-integration
branch
from
6f918fb to
5f43efa
Compare
|
@phsft-bot build |
|
Starting build on |
|
Thanks for the patch! |
6 participants
Dear ROOT team,
while integrating some CMake functionality provided by ROOT through the
ROOT_USE_FILEinclude into our project, some small issues came up. If we are mistaken and there are better solutions than the one I provided, your advice is very welcome.Our
FindROOT.cmakeimplementation looks like this:which is called in a
CMakeLists.txtlike thisfind_package(ROOT 6.10.04 REQUIRED)Please see the commit messages for more details about the issues we had.
Best regards,
Dennis