-
Notifications
You must be signed in to change notification settings - Fork 570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TriBITS: cmake gets incorrect Trilinos_INCLUDE_DIRS on installed System #10100
Comments
@e4t, thanks for reporting this. I am in the middle of refactoring this code as part of a larger refactoring (see Epic TriBITSPub/TriBITS#367) and I will take a look at this. But note that newer versions of TriBITS/Trilinos are moving to modern CMake targets where client CMake projects will just be linking to IMPORTED targets which know about their include directories. See: But I will have a look. (I saw that code but I did not write it and was not sure what the logic was so I will write some unit tests and fix this.) |
@bartlettroscoe, thanks for the feedback! I've read about the TriBITS restructure: from what I read in the CMake documentation using the export/import mechanism seems to address the relocatable package issue in a more consistent manner without requiring extra logic. So this issue may be moot. |
@e4t, also related to this issue is the item "Use standard install locations defined by the standard |
This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. |
Bug Report
@trilinos/TriBITS
Description
When <project_name>__INSTALL_LIB_DIR and <project_name>_INCLUDE_DIR are of different path type (ie relative/absolute) or have a different root paths, the logic in
cmake/tribits/core/package_arch/TribitsWriteClientExportFiles.cmake
to determine the <package_name>_INCLUDE_DIRS for <package_name>Config_install.cmake may be wrong.Reason: The path is calculated relative to
${CMAKE_CURRENT_LIST_DIR}
by counting the number of directory elements in${PROJECT_NAME}_INSTALL_LIB_DIR
backwards. With <project_name>__INSTALL_LIB_DIR being an absolute path, this will take the path back to/
. When <project_name>_INCLUDE_DIR is relative, this will simply be appended, ignoring any setting of CMAKE_INSTALL_INCLUDEDIR.I'm afraid the logic to obtain a relocatable path will only work reliably when both paths are relative. Thus, if any one of these aren't one should probably give up on the idea to make the installation relocatable - or at least prepend the value of CMAKE_INSTALL_INCLUDEDIR to any relative path (this will still give the wrong results if <project_name>_INCLUDE_DIR is not below CMAKE_INSTALL_INCLUDEDIR).
Steps to Reproduce
build/packages/kokkos/CMakeFiles/KokkosConfig_install.cmake
will have:The former (
Kokkos_INCLUDE_DIRS
) is clearly wrong with CMAKE_CURRENT_LIST_DIR being/usr/local/lib64/cmake
, this will point to/include/trilinos
.make; make install
FindPackage(Trilinos)
Trilinos_INCLUDE_DIRS
Expected result:
/usr/local/include/trilinos
Actual result:
/include/trilinos
The text was updated successfully, but these errors were encountered: