This post was flagged by the community and is temporarily hidden.
The following statement in the article is unfortunately misleading:
Catkin has been replaced by colcon …
Since the article itself doesn’t offer to provide comments I want to point future readers here to this design doc which describes the difference between the build systems (e.g.
CMake, the CMake API of
ament_cmake) and the build tools (
@dirk-thomas, absolutely right!
Would it be more correct to say that colcon has been selected as build tool now for ROS2 and ROS1, versus the previously used cakin_tools build tool only for ROS1?
And that where users in ROS1 one previously used catkin_make command now will use the colcon build command?
Please correct me otherwise so that future readers can have this matter cristal clear.
No,not for both ROS versions. We only recommend
colcon for ROS 2 at the moment.
For ROS 1 we still recommend using
catkin_tools is also not the recommended tool even though many users are successfully using it),
The following ticket contains some more context why we don’t recommend using
colcon for ROS 1 even though it should be perfectly able to do the job (and offer many more features than the currently recommeded tool): https://github.com/colcon/colcon-core/issues/149
As a part of transition to ROS2 I would like to start using colcon + ament_cmake in ROS1 kinetic project. What would be the recommended process to adopt ament_cmake?
You should be able to use
colcon instead of any of the ROS 1 build tools (
catkin_tools). While we don’t recommend it at the moment (since we didn’t test it thoroughly) it should work.
ament_cmake isn’t available in ROS 1 and I don’t recommend trying to use it in ROS 1. There are subtle differences how
ament_cmake work and mixing them in ROS 1 is certainly not recommended.
Thank you Dirk! It would be nice to make ament_cmake & Co available for ROS1 projects. The reason is the complexity of ROS2 porting - splitting the process into a few well-isolated steps (colcon, ament_xxx, code, …) would greatly simplify porting large projects with multiple contributors.
I suggested the same rationale, as I wanted to use
ament_cmake in ROS 1 to better share some of the rviz code between ROS 1 and ROS 2, but I think we just didn’t have time to do it.
One other option was to use pure cmake code when sharing a package between ROS versions, because it is supported in both, but obviously that’s not a very attractive solution at scale, as you loose all the benefits of catkin and/or ament.