ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Catkin adds hardcoded paths to auto-generated .cmake files

asked 2020-09-16 05:24:45 -0600

Dwil gravatar image

updated 2022-01-22 16:16:16 -0600

Evgeny gravatar image

Hi all,

I notice that catkin creates hard coded paths in the auto-generated .cmake files when building catkin packages that link/include against plain .cmake files. This is noticeable with robot_state_publisher and kdl_conversions including paths to the install space of orocos_kdl header and library paths.

Is this just a function of catkin_make_isolated?

Is this by design so that you can guarantee to find this library and header for any subsequent build?

Is there anyway to turn this off, it makes my installation space non-relocatable.

Thanks, Dan

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-09-16 11:29:41 -0600

Dirk Thomas gravatar image

Since plain .cmake files often provide CMake variables with absolute path a ROS package shouldn't directly embed them into the generated CMake config files.

Instead a ROS package should use a CMake extra file (see catkin_package(CFG_EXTRAS ...)) to find the dependency at usage-time of the ROS package (rather then at build-time) and add its information to the CMake variables provided by the ROS package (e.g. <pkgname>_INCLUDE_DIRS).

Usually this extra effort isn't done when the plain CMake dependency is a system package since it isn't expected to be moved around anyway. For non-system packages it is good practice to use the described approach to keep the ROS package relocatable.

edit flag offensive delete link more


Hi Dirk,

Thanks for the reply. So would you describe orocos_kdl as system package? Is it the fault of robot_state_publisher not using including the orocos_kdl package correctly hence the hardcoded paths?

OrocosKDLTargets.cmake and orocos_kdl-config.cmake files don't seem to use absolute paths yet the robot_state_publisher Config.cmake file still includes absolute paths to both include folder and library of orocos_kdl. This also happens with packages like Geometry2 when building tf2_kdl tests and kdl_conversions.

Dwil gravatar image Dwil  ( 2020-09-16 13:26:27 -0600 )edit

orocos_kdlis not a system package since it is listed as a ROS package in the distribution:

Its CMake config file does provide absolute path: set(orocos_kdl_INCLUDE_DIRS "${CMAKE_CURRENT_LIST_DIR}/../../../include;;/usr/include/eigen3").

When downstream packages like robot_state_publisher just call find_package(orocos_kdl) and catkin_package(DEPENDS orocos_kdl) it will result of that absolute path from orocos_kdl_INCLUDE_DIRS to be embedded in the CMake config file of that package.

So yes, the fault is at the downstream packages like robot_state_publisher. They should not export the dependency using DEPENDS but defer resolving the orocos_kdl dependency into a custom CMake extra file.

Dirk Thomas gravatar image Dirk Thomas  ( 2020-09-16 15:11:48 -0600 )edit

Ok great. Thank you for your response. Sorry for all the questions! I haven't found much information on this hard-coded path issue so hopefully this will clear it up for others too.

So does this happen because downstream packages are including plain .cmake packages? Why doesn't this happen when you declare a dependency to a catkin package? e.g catkin_package(DEPENDS <catkin_package>) without the need for a custom -extra.cmake file? Can I just follow this to adjust the packages that are depending on orocos_kdl incorrectly? Do I need to make a custom .cmake file or can I just include the orocos .cmake files for export? Do you know of any examples I could look at to make these custom .cmake files?

Thanks again!

Dwil gravatar image Dwil  ( 2020-09-16 16:10:29 -0600 )edit

catkin packages are treated differently by the logic exporting the information for DEPENDS:

That is why it works automatically for catkin packages but not for others - simply because we can't assume that they adhere to a certain conventions.

You will need a custom <pkgname>-extras.cmake.*. It needs to call find_package(orocos_kdl REQUIRED) as well as combine all needed variables e.g. list(APPEND @PROJECT_NAME@_INCLUDE_DIRS ${orocos_kdl_INCLUDE_DIRS}), the same for *_LIBRARIES etc.

Dirk Thomas gravatar image Dirk Thomas  ( 2020-09-16 17:01:18 -0600 )edit

Perfect. Thank you very much for your help. I will give it a go.

Dwil gravatar image Dwil  ( 2020-09-16 17:12:31 -0600 )edit

Hi Dirk,

This worked just great thank you. However, I only needed the find_package(orocos_kdl REQUIRED) section and had to remove the list(APPEND @PROJECT_NAME@_... sections.

My reasoning below: In catkin_package.cmake


This adds all ${PROJECT_NAME}_INCLUDE_DIRS to the variable PROJECT_INCLUDE_DIRS. Later on in the installation space this happens :

foreach(idir ${PROJECT_INCLUDE_DIRS})

if(IS_ABSOLUTE ${idir})

list_append_unique(PROJECT_CMAKE_CONFIG_INCLUDE_DIRS "${idir}")

So if I include the list(APPEND ... in the -extras.cmake file any consuming package of this package then adds the hardcoded paths to it's .cmake file in the install space.

Did I do something wrong or can you confirm this is ok?

Dwil gravatar image Dwil  ( 2020-09-17 07:16:07 -0600 )edit

Hm, you are right. That is indeed undesired. I don't understand how you are using the include directories / libraries of the found package if you don't pass the variables anywhere?

Dirk Thomas gravatar image Dirk Thomas  ( 2020-09-17 11:09:07 -0600 )edit

I don't need to pass the variables at build time due to find_package(orocos_kdl REQUIRED) in the -extras.cmake file setting orocos_kdl_LIBRARIES and orocos_kdl_INCLUDE_DIRS. Then in the future install any package that consumes that package will just have the -extras.cmake file automatically included and those libraries/headers will be found?

Dwil gravatar image Dwil  ( 2020-09-17 12:00:55 -0600 )edit

Question Tools



Asked: 2020-09-16 05:01:49 -0600

Seen: 855 times

Last updated: Sep 16 '20