REP: 145 Title: ROS Buildsystem Evolution (post-catkin, ament buildsystem) Author: Thibault Kruse Status: Draft Type: Process Content-Type: text/x-rst Created: 08-Jul-2015 Post-History:
This REP suggest changes to the current ROS buildsystem catkin [2]. The changes to be made are a refactoring of the cmake code into modules, and extensions for ROS2/DDS message generation.
There are ongoing discussions in the Next Generation ROS Special interest Group [7].
The goal of this REP is to establish a buildsystem which:
- has a command like catkin_tools (build packages in isolation, in parallel where possible)
- has a restructure cmake code of catkin_cmake to allow several extensions (like including gmock, or changes to message generation).
- changes the build output avoiding the devel_space, using an install target that creates symlinks to source files for executables
The removal of a devel_space is not a technical necessity but an overall improvement of the usability and the buildsystem codebase.
The ROS ecosystem provides a home to thousands of individual software packages providing features in the context of robotics. The packages are written in languages like C++, Python, Common LISP, and Java. The packages are maintained at diverse robotic labs and universities around the world. Given that a complex humanoid robot is likely to require hundreds of such packages to work, it is necessary to have a software system that can build a large set of packages reliably and fast. Also, it is the desire of the ROS community to provide those packages to be installed as binaries in common Linux distributions (and possibly Windows), which makes it necessary to maintain a build farm continuously building and releasing all known ROS packages and reporting build failures.
The current standard ROS buildsystem is catkin [2], it has replaced the previous buildsystem rosbuild [1] since the ROS Groovy distribution.
These factors drive the motivation to make major changes:
- Some design decisions of catkin make it difficult to detect and fix errors.
- The global C++ and Python development tool landscape changes, and catkin's current code structure makes it difficult to incorporate new tools (such as gmock)
- The prototyping around ROS2 (ROS on top of DDS) require changes to the generation process of message bindings for different DDS implementations.
Some historical context: The first releases of ROS were shipped with a system called rosbuild (using a command called rosmake). In ROS Fuerte some core packages were build using an early version of the catkin buildsystem. After several unusually controversial discussions, this buildsystem was then changed to the first publicly used catkin version shipped with ROS Groovy, which remains largely unchanged in usage and structure until today.
The main reasons for introducing catkin as a replacement for rosbuild were to create binaries in the standard FHS layout to allow easy packaging, cross-compilation of sources and improve the speed of release builds on the build farm ([3], [4], [5]).
Limitations in with the catkin_make command led to the creation of catkin_make_isolated (cmi [10]), which could also build e.g. plain cmake packages (besides catkin packages).
Based on cmi, catkin_tools [8], [9] was developed to parallelize isolated builds and provide more convenience functions.
In 2014, OSRF began developing a buildsystem prototype called ament [6] based on the sources of catkin and catkin_tools. The experience with ament show the changes in the REP to be feasible.
For the sake of the changes, a simplified view of catkin is that it has 3 virtual parts:
- catkin_pkg: Parsing and tooling for package manifests (package.xml)
- catkin_cmake: The cmake macros required to compile and generate code based on CMakeLists.txt
- catkin_make: A command to trigger the build of a whole workspace, offering a range of options to manipulate the build process. This treats all projects within a workspace as a single cmake project, which may cause unexpected results.
In addition, there are the following artifacts related to catkin relevant to this discussion:
- catkin_simple: An alternative CMake API as an attempt to simplify catkin_cmake
- catkin_make_isolated (cmi [10]): An alternative command to catkin_make building packages in isolation, sequentially (very slow)
- catkin_tools [8], [9]: Alternative command building each package in isolation, in parallel (plus several further usability enhancements)
The goal of having a command similar to catkin_tools can trivially be achieved by using catkin_tools, but in combination with the other requirements of this REP, a fork might be a viable alternative.
The restructuring of the catkin_cmake part ... TODO
The change of the build output from offering a devel_space to offering symlinked installs requires more explanation:
There are differences working on a robotics project with ROS from developing most other software.
- In the ROS ecosystem the C++ and Python languages are used the most.
- Also it is common to actively work on more than one package as the same time.
- Manually testing code frequently involves starting and stopping many executables and processes on a robot, which is only realistically possible using launch scripts (rosrun and roslaunch)
Since rosbuild, the ROS community has created tools to enable developers in robotics to work more efficiently with the specific situation in the ROS ecosystem.
Since C++ code requires compilation while Python does not, developing in C++ has a different workflow from developing in Python.
Using C++, the small development cycle is to change the code, run a compiler, then execute the code. If several packages are involved, then with standard build tools the first package has to be build, then installed, then the second package has to be build against the installed first package, then the code can be run.
Working with Python, the source files the developer edits can be used for execution without a compilation step. However, for the code to be invoked from roslaunch/rosbuild, the python files need to be placed where the launch tools can find them.
The rosbuild system avoided the installation step by building against the compilation result, not against an install result, and running scripts from the source folder.
The catkin_make command avoids the installation step by building all projects as if they were a single project, and providing a devel environment which has symlinks for python scripts in the source folder, and otherwise tries to mimic being an installation location.
The catkin_tools based command avoids the installation step by providing many devel environments (one for each package) having symlinks for python scripts.
These tools allow for development cycles like this:
- change some C++ files in several packages
- run a single build command (for C++, not python)
- run a launch command to start many processes
This REP suggests to keep this workflow possible, but to choose a different solution from catkin.
TODO
The new buildsystem requires no change to the package manifest formant (package.xml).
The following changes to the CMakeLists.txt would be required for a ROS1 package to be build with the new buildsystem:
TODO
There are multiple alternatives of how to introduce tha changes to the ROS community. Concerns exist about:
- Disrupting developers working on ROS1
- Breaking the build farm
- The effort to maintain, test, document, use and learn 3 buildsystem at the same time
- The effort to change ROS1 packages just to be built with the new buildtool
- The effort to discuss all the changes and alternatives
- Bad publicity
TODO
The following alternatives exist for how to realize the evolution of the buildsystem:
Pro:
Contra:
- risk of regression
- slow development
Pro: * Maybe not perceived as third active ROS buildsystem (since it deprecates catkin) * code reuse between ros1 and ros2
Contra:
Pro:
- already exists
- Zero risk of regressions in ROS1
- Python 3 exclusivity (TODO, explain more)
- Additional improvements difficult to add to catkin
Contra:
- Perceived as third active ROS buildsystem
- No code reuse
- catkin2, catkin2.0
- ament
A reference implementation of this buildsystem that only builds ROS2 packages has been created under the name ament [6].
ament has a refactored cmake code that is more modular than in catkin, and has different extensions point that make it possible to generate ROS message bindings for multiple DDS implementations in multiple languages.
ament uses a command that basically works like the command in catkin_tools, building packages in isolation with parallel builds.
ament does not create a devel_space, but achieves the same kind of workflow by having an option to install symlinks to the source-space.
Aside from the goals mentioned in this REP, the prototype also provides these changes from catkin:
- Python scripts only work on Python3, not Python2
- New package_resource_indexer for fast searches of installed packages
- AMENT_PREFIX_PATH used instead of CMAKE_PREFIX_PATH
| [1] | rosbuild (http://wiki.ros.org/rosbuild) |
| [2] | (1, 2) catkin (http://wiki.ros.org/catkin) |
| [3] | catkin_vs_rosbuild (http://wiki.ros.org/catkin_or_rosbuild) |
| [4] | catkin_review (http://wiki.ros.org/catkin/Reviews/2012-08-01_API_Review) |
| [5] | catkin_review2 (http://wiki.ros.org/catkin/Reviews/2012-08-07_API_Review) |
| [6] | (1, 2) ament (http://design.ros2.org/articles/ament.html) |
| [7] | ament_discussion (https://groups.google.com/forum/#!topic/ros-sig-ng-ros/gyToaPoiQi4) |
| [8] | (1, 2) catkin_tools1 (https://groups.google.com/d/msg/ros-sig-buildsystem/UdgxD7AZTzM) |
| [9] | (1, 2) catkin_tools2 (https://groups.google.com/forum/#!topic/ros-usability-scripts/C4NynpfQPcE) |
| [10] | (1, 2) cmi (http://www.ros.org/reps/rep-0134.html) |
This document has been placed in the public domain.