How do I add catkin workspace into cmake tree?

asked 2017-06-08 18:42:28 -0500

nevermore gravatar image


I am faced with a problem: I cannot use add_subdirectory() (for example, catkin_metapackage() cannot locate package.xml and CMakeLists.txt in sources) for catkin workspace to include it into my cmake project (there tons of pure-cmake legacy code). It seems, that the problem is catkin assumes that its CMakeLists.txt is the top-level list in a project (I took a look on catkin sources and found that it often refers to ${CMAKE_SOURCE_DIR} and ${CMAKE_BINARY_DIR}). My catkin packages uses libraries from legacy code and I know, that I could split my project into two (catkin and non-catkin) and use cmake exports, but that would be the hell I guess.

Are there any workarounds?

edit retag flag offensive close merge delete


Have you tried adding packages individually? I'm not sure adding entire workspaces is supposed to work.

Provided the environment is setup correctly catkin pkgs are basically CMake pkgs, so adding them separately should work.

gvdhoorn gravatar image gvdhoorn  ( 2017-06-09 01:14:11 -0500 )edit

Yeah, I tried and that works for building. In this case no ROS environment will be generated but I need it to start my nodes via roslaunch.

nevermore gravatar image nevermore  ( 2017-06-09 03:50:47 -0500 )edit

Do you actually need to include your ROS workspace that way? If your "tons of pure-cmake legacy code" are actually just libraries and headers that you'd like your ROS nodes to make use of, then couldn't you treat those libraries as system dependencies and link them in the regular way?

gvdhoorn gravatar image gvdhoorn  ( 2017-06-09 03:52:31 -0500 )edit

Similar to how we use Boost, Eigen and other CMake-built projects in ROS (find_package(..) etc).

gvdhoorn gravatar image gvdhoorn  ( 2017-06-09 03:53:18 -0500 )edit

There are not only legacy code. We develop some of those libraries intensively (to use with ROS packages).

nevermore gravatar image nevermore  ( 2017-06-09 04:03:28 -0500 )edit

Can you explain how that changes things? Best practice is to write ROS-agnostic libraries, install them and then wrap them in a thin ROS-wrapper, treating the libraries as system dependencies (ie: not as ROS pkgs themselves). This should work regardless of whether the code is old or new.

gvdhoorn gravatar image gvdhoorn  ( 2017-06-09 04:09:53 -0500 )edit