make installed code relocatable

[dirk-thomas]

Installed code should not (or as few as possible) contain absolute path information. Currently a lot of code contains the CMAKE_INSTALL_PREFIX.

One goal would be to compile a workspace with DESTDIR=/tmp/destdir catkin_make_isolated --install and be able to build another workspace on top of that.
At best it should be possible to run everything from the installed workspace and run the tests of workspaces built on top.

The following things need to be updated to not use absolute paths:

• env.sh references setup.sh, 9cfba6f
• setup.SHELL references setup.sh, 9cfba6f
• setup.sh references _setup_util.py,
  sourced shell scripts can not determine their own path therefore enable the user to override the default path via an environment variable, using CATKIN_SETUP_DIR, 9cfba6f
• _setup_util.sh contains abs. path to prefix CPP,
  should be passed in from setup.sh, 9cfba6f
• generated CMake config files, e.g. include directories, 74af67d
• environment hooks,
  require context about their workspace from the outside, setup.sh need to provide that individually for each environment hook, using the environemt variable CATKIN_ENV_HOOK_WORKSPACE for that 44b3234
• catkin_make_isolated must set the environment variable to override the base path when building with DESTDIR, 7282a4b

Changes required in other packages:

• CMake extra files,
  should utilize ${@(PROJECT_NAME)_DIR}/../../.. to achieve the same as @(CMAKE_INSTALL_PREFIX), ros/gencpp@e5acaf6, ros/genlisp@42458c1, ros/genpy@1bc78ac, ros/ros@3681bd0, ros/ros_comm@e0366e1,
  ros/roslisp@58657c8
• environment hooks, ros/ros@3681bd0

Message Generation:

• the generated CMake files contain absolute paths to message/service files, ros/genmsg@cb45b13

All patches are committed to the relocatable branch of the respective repos. A file to checkout the modified repos using https://github.com/dirk-thomas/vcstool can be found here: https://gist.github.com/dirk-thomas/6092081

[herbrechtsmeier]

@dirk-thomas Please correct the dynamic_reconfigure_BASE_DIR in extras.cmake.em of dynamic_reconfigure also.

[herbrechtsmeier]

@dirk-thomas I have test the patches and they work. Nevertheless I would proposed to replace ${@PROJECT_NAME@_DIR}/../../../@(CATKIN_PACKAGE_BIN_DESTINATION) with a new global catkin variable ${@PROJECT_NAME@_BIN_DIR} which could be overwrite (passed) by the build environment to point to the native system root. Otherwise we get problems when somebody use the path for binaries instead of python scripts.

[dirk-thomas]

I am glad to hear that it works for your use case.

Regarding the variable: this variable should not be overwritten - not even for cross compilation. If a package requires compiled binaries to build itself / downstream stuff it needs to reference that using a separate variable pointing to a different directory. E.g. in the case where a package uses both (a Python script as well as a compiled binary) to build downstream stuff it will not have both of the executables in the same directory anyway.

Each package should consciously deal with this in its CMake extra file. catkin should not try to populate any package-specific variables. For the source/devel space catkin would not even be able to set a reasonable directory since it just does not know where the binaries in the package are.

[herbrechtsmeier]

In that case the binaries need to use the find_binary function to get the real path of the binary.

As the long time goal it would be nice if catkin and the CMake extra files always use the find_binary function to get the real path of all executed scripts and binaries. This enables the cross build environment to use all binaries and as well scripts from the native system root if it doesn't install any binaries and scripts into the cross system root.

[dirk-thomas]

For packages which do not generate compiled binaries it can stay the way as it is with these patches. I don't see a reason to change that even in the long term.

For compiled binaries we should indeed use the find_* CMake functions. But that should handled by the first package which actually requires that. Currently no (wet) package requires compiled binaries during the build (as far as I know) and that was an important goal of the new buildsystem.

I will go ahead and merge all above mentioned patches. Releases for the separate packages will follow when ever each package has "enough" changes accumulated.

[herbrechtsmeier]

As long as the build machine (native system root) and cross compiled machine (cross system root) use the same python version it doesn't matter which python script is used and its a design decision.

@dirk-thomas thanks for your work. We will update our recipes in meta-ros after you have apply the different patches.

[dirk-thomas]

All repos listed in this ticket has been updated to be relocatable - therefore closing this ticket.

In case other repos use CMAKE_INSTALL_PREFIX in the CMake extra files please fill further tickets against these repos directly.