Make installed CMake files relocatable

[herbrechtsmeier]

This pull request makes the installed CMake files relocatable. This function is needed to cross compiling ros via yocto project. It adds @PROJECT_NAME@_EXTRAS_DIR to the pkgConfig.cmake.in and set it to the CMAKE_CURRENT_LIST_DIR. This directory is used to include the PKG_CFG_EXTRAS files.

[dirk-thomas]

How do you think you want to address other files which contain absolute paths i.e. the generated env/setup/_setup_util files in the root of the devel/install space? Do you require all of them to contain relative paths only?

[herbrechtsmeier]

I disable the env/setup/_setup_util files because I install everything into the system root. At the moment I don't see a reason why they should use relative paths.

[tfoote]

Can you explain a little bit about why you need things to be relocatable? It is standard to cross compile or compile in chroots using DESTDIR and CMAKE_INSTALL_PREFIX, (PREFIX in make style systems. ) Such that everything is referenced to CMAKE_INSTALL_PREFIX, but the installation goes inside DESTDIR before being deployed to a different filesystem.

DESTDIR reference: http://www.gnu.org/prep/standards/html_node/DESTDIR.html

Using DESTDIR with cmake: http://www.cmake.org/pipermail/cmake/2009-April/029017.html

[herbrechtsmeier]

The problem is not the installation but the usage of other packages during cross compile. The other packages files (dependencies) are copied from the DESTDIR to a cross compile system root somewhere on the system. Additionally the same package files are copied to the cross compiler toolchain installation directory or the system root on the machine which is /. Therefore all the paths in the files must be relative to the DESTDIR and dynamic prepend with the current system root. In pkg-config you can set the PKG_CONFIG_SYSROOT_DIR to the system root and it update all include and lib paths. In cmake you can use CMAKE_FIND_ROOT_PATH therefore but only if the software don't set NO_CMAKE_FIND_ROOT_PATH and if the software always use find_xxx. So you can always use find_file to find the file in the system root or you can calculate the current path in your projectConfig.cmake and use this in all cmake files.

[tfoote]

NO_CMAKE_FIND_ROOT_PATH was ticketed to be added to support cross compiling here: https://code.ros.org/trac/ros/ticket/2994 I believe this is where the usage started from. @snorridj can you comment on the relevancy?

[herbrechtsmeier]

If you search files in the source of your project (from your devel space) or in the devel space itself you have to use NO_CMAKE_FIND_ROOT_PATH.

[herbrechtsmeier]

The second use case could be avoid when you add the the devel spaces to the CMAKE_FIND_ROOT_PATH. This have the advantage that you have full control over the usage of the devel spaces and you could deactivated the local devel space of the current compiled package.

[herbrechtsmeier]

I have open ros/catkin:379 and ros/catkin:380 to discuss the other topics there. Back to the main topic of this issue what argues again adding a dynamic calculated @PROJECT_NAME@_EXTRAS_DIR to the @PROJECT_NAME@Config.cmake and use this as base for all local extra files. The files in the source directory could be passed via absolute path.

[dirk-thomas]

That is a good idea. I can look into making the necessary changes to pass some of the cmake files with absolute paths and some with relative paths. That way we should be able to achieve the original goal of making the installed files relocatable.

[dirk-thomas]

@herbrechtsmeier Can you please test the branch reference_extra_files_relatively, verify that it does what you wanted to achieve and report back?

[herbrechtsmeier]

@dirk-thomas It works as expected.

[dirk-thomas]

Thank you for your patch. Closing in favor of modified version in #385.

[herbrechtsmeier]

@dirk-thomas Does a dynamic variable exists which points to the data directory (@PROJECT_NAME@_DIR/..)? The path in the pkg-msg-paths.cmake.in need to be updated to the current absolute path.

[dirk-thomas]

@PROJECT_NAME@_DIR is set when you do a find_package() call. There is no generic variable which points to the parent folder.

Can you please clarify what you mean with "pkg-msg-paths.cmake.in need to be updated"?

[herbrechtsmeier]

At the moment genmsg save the path to the msg directory in the @PROJECT_NAME@-msg-paths.cmake which don't work as this is not an absolute path. It is only the path relative to the system root. I add the following lines to the pkg-msg-paths.cmake.in and set the PKG_MSG_INCLUDE_DIRS to "${${PROJECT_NAME}_MSG_INCLUDE_DIRS_INSTALLSPACE}" in genmsg-extras.cmake.in for the install space case to generate the absolute path.

if(NOT IS_ABSOLUTE ${@PROJECT_NAME@_MSG_INCLUDE_DIRS})
  set(@PROJECT_NAME@_MSG_INCLUDE_DIRS ${@PROJECT_NAME@_DIR}/../${@PROJECT_NAME@_MSG_INCLUDE_DIRS})
endif()

[dirk-thomas]

First the assumption that the root of a package is one level above pkgname_DIR is not very safe.
Second as far as I can see @PROJECT_NAME@-msg-paths.cmake (i.e. for std_msgs) does not contain relative but absolute paths. Can you point to a package where this is not the case?

[herbrechtsmeier]

The cmake path and msg path have both the same prefix (${CMAKE_INSTALL_PREFIX}/share/${PROJECT_NAME}) but you are right that a variable for the data directory would be better and that is the reason for my question above.

Maybe I shouldn't use the words relative and absolute in this context. The path in the current @PROJECT_NAME@-msg-paths.cmake is an absolute path but this doesn't mean that this is the actual path. The absolute path always reference the system root path. Normally the system root path is empty but during cross compilation the system root path is the path to the target (or native) system root which prepends all absolute paths. Cross compilation mean you compile your software with the configurations it should have on the target but this means that your paths aren't equal to there actual installation path. Therefore CMake allows you to define additional system root paths (CMAKE_FIND_ROOT_PATH) which prepends the common search path of the find_xxx functions.