Include map2d_nws_ros2_msgs in the main CMake build via add_subdirectory?

[traversaro]

Hi @elandini84, @randaz81, @drdanz, I was looking at the repo installation instructions (in view of possible integration in the future with https://github.com/robotology/robotology-superbuild). I noticed that at the moment the installation instruction have two steps:

• First, use colcon to build, configure and install the map2d_nws_ros2_msgs CMake/Ament package
• Then, use cmake to build the yarp-ros2 package, that finds via find_package the map2d_nws_ros2_msgs CMake package.

Do you think it would be possible instead to just include via add_subdirectory the map2d_nws_ros2_msgs directory and then link to the map2d_nws_ros2_msgs CMake target? This would permit to configure the repo with a single cmake invocation, as it is typical done with CMake projects.

cc @ahoarau

[traversaro]

Note that using the ROS/ROS2 packages just as libraries instead of adopting all the build workflow of ROS/ROS2 is fully supported, it is just not really document at the moment, see https://discourse.ros.org/t/migrating-ros-ros2-off-of-catkin-colcon-towards-pure-cmake/12104 for a related discussion.

[drdanz]

If there is a way, I'm 100% in favour, but when we tried, the problem was that we needed the setup.bash file created by colcon because otherwise the rpc services are not available from the ros2 command line utility.

[ahoarau]

Same here. Plain cmake is easy, but the setup.bash was required. Can we duplicate what's in there as CMake variables ?

[traversaro]

If there is a way, I'm 100% in favour, but when we tried, the problem was that we needed the setup.bash file created by colcon because otherwise the rpc services are not available from the ros2 command line utility.

Thanks, I wanted exactly to understand what was the blocking aspect here, as the intention is in theory for ROS/ROS2 functionality to work fine even from plain CMake (see the discussion in https://discourse.ros.org/t/migrating-ros-ros2-off-of-catkin-colcon-towards-pure-cmake/12104 and https://github.com/gerkey/ros1_external_use https://github.com/gerkey/ros1_external_use/tree/ros2). For example, in icub-models and the related activation scripts (https://github.com/robotology/robotology-superbuild/blob/4d463fed1ccda090cc7fba779eb20f3319e9dea5/cmake/template/setup.sh.in#L26 and https://github.com/robotology/robotology-superbuild/blob/1600741a75544704abc45f08820b6bb77f1fd7cc/conda/multisheller/icub-models_activate.msh#L10) we support ROS2 by just setting AMENT_PREFIX_PATH, so I suspect something similar is possible here, I will check it out.

If something instead is actually missing that explicitly requires colcon to be used, I think we could raise the issue back to the specific part of ROS2 affected, as I think not tightly coupling ROS2 functionalities with the build tool is a goal.

[traversaro]

I briefly tested this in the context of https://github.com/RoboStack/ros-galactic/issues/14, and it turns out that indeed appending the ${CMAKE_INSTALL_PREFIX} directory to the AMENT_PREFIX_PATH environment variable, is sufficient to make sure that map2d_nws_ros2_msgs pkg is found by ros, at least in a way that is displayed in ros2 pkg list .

[traversaro]

Note that using the ROS/ROS2 packages just as libraries instead of adopting all the build workflow of ROS/ROS2 is fully supported, it is just not really document at the moment, see https://discourse.ros.org/t/migrating-ros-ros2-off-of-catkin-colcon-towards-pure-cmake/12104 for a related discussion.

The situation on this is probably improving in the near future thanks to @alsora from iRobot, see https://github.com/ros2/ros2_documentation/pull/1913 :

Developer experience: Better integration of ROS 2 repos with package managers and documentation for building/running ROS 2 applications. Building ROS 2 applications with pure CMake and without colcon is not easy as it should be. Moreover ROS 2 does not integrate well with already existing package manager solutions such as conan. Running ROS 2 applications also faces many problems and challenges if the default setup.sh scripts are not used. The purpose of this work is to provide improvements and documentation to support all these "non-default" use cases.

@alsora Thanks a lot for working on this! I am not sure if you already have a detailed plan on how to handle that, but in my limited experience it would be great to have something like https://github.com/gerkey/ros1_external_use but for ROS2.