ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Colcon / ament_tools /?

ros2

#1

I’m trying to ascertain how to best integrate the Ada tooling into the build process of ROS2. I thought that amend_tools was the way to go, seeing that Java, D, Rust all go that route.

Almost by chance I have seen Issue #168 in the ros2/design repo where it says colcon is the new build tool. But in the top of http://design.ros2.org/articles/build_tool.html it says nobody is working towards this. Also I find no thread in the Discourse with colcon in it. http://design.ros2.org/articles/ament.html doesn’t mention it either.

I’m a bit confused at this point. Further, the separation between build tool and build system argued in the colcon page seems to be one of the features of amend_tool.

My instinct tells me to forget about colcon and work with amend_tools, but I might be missing the big picture.

So… any thoughts on this?


#2

The referenced PR to the design article updates the “top” existing article to update it to reflect the current state (see https://github.com/ros2/design/pull/168/files#diff-361c5cb5b98ec5e7f690f2dbce2cd7fdL22).

We are currently rolling out the new build tool but the PR hasn’t been merged yet and the wiki instructions haven’t been updated yet. We are using the tool on ci.ros2.org as well as locally to polish things before recommending it to be used by everyone. So for now you can use ament_tools as before. Within a week or so we will hopefully move forward with these and recommend using colcon to build ROS 2. At that time we plan to also post the information on discourse.

the separation between build tool and build system argued in the colcon page seems to be one of the features of amend_tool

The separation is not only about having two separate packages / repositories. But also about the naming as well as the ability to not be limited to a single project. The name ament_tools suggests that it only works with ament(_cmake) which is mostly also the case. The goal of colcon is not be tied to ament(_cmake) or ROS 2. Instead it can be used to build ROS 1 as well as e.g. Gazebo including the ignition packages which don’t even have package.xml files. Integration of any external tooling or build system should be easier with colcon as it offers many more extension points.


#3

Great, thanks for the information. So colcon is moving forward then.

This is important to my case because Ada has its own build system because of language-mandated checks and I’d prefer to go with proper integration from the start instead of patching it through CMake to have to redo it at a later time.

Given what you say I’m going to go straight for colcon and see if I can get my bearings around. I suppose documentation will be scarcer than for catkin/amend, so… should I monitor the relevant PRs or do you recommend any other ways of staying on top of this matter?

Thanks!


#4

That is certainly the case. sorry about that. Let me know if you have any specific questions and I am happy to help.

It depends mostly on how “deep” you want to be. If you only mind about the “public” announcement listening to discourse will be sufficient. If you want to get more involved / informed on the progress you can subscribe to the referenced design PR and/or consider watching some of the colcon repositories.

If you end up working on an extensions to colcon I recommend to consider placing it under the colcon org unit (see rtd for more info why).


#5

That is certainly the case. sorry about that. Let me know if you have any specific questions and I am happy to help.

I’ll probably take you up on the offer in the near future :wink: For now I’ll focus on other aspects of the binding while the dust settles.

If you end up working on an extensions to colcon I recommend to consider placing it under the colcon org unit (see rtd 3 for more info why).

Good to know. I’ll keep that in mind, thanks.


#6

Is there any equivalent to catkin config, catkin clean in colcon? Building a single package without --packages-select would be nice too, like it is possible with catkin. So far colcon looks like a bad version of catkin tools to me. I hope it’s only because I’m not used to it yet. Are there plans for more features in colcon?


#7

colcon doesn’t have profiles but offers different concepts:

  • metadata to provide information about packages
  • defaults to set the default values of command line arguments
  • mixins to define sets of configuration options which can be combines

The most significant reason why mixins are favored over profiles is that they are combinable which makes it feasible to share mixins between users encouraging reuse (e.g. https://github.com/colcon/colcon-mixin-repository). Supporting something similar than a default profile would certainly be good - I guess it has not been implemented yet since it is not yet clear how best to do so / how best to use such a feature.

It should be fairly straight forward to add this feature to the package-selection extension. Please consider to create a PR for it.

One thing to consider is that there can only be one kind of positional arguments like this. Package names to be selected seems like an obvious choice. It might just be that for other use cases other positional args would make more sense. That is why currently all command line options are named arguments (and also have pretty verbose names to avoid collisions of the numerous options).

That might highly depend on your point of view. catkin_tools has certainly some nice usability features which colcon doesn’t have at the moment.

But on the other hand there is a pretty long list of features in colcon which go beyond what catkin_tools can do (just a short excerpt):

  • works on all targeted platforms (Linux, macOS, Windows)
  • supports the current features of package manifest files including group dependencies
  • supports packages without a package.xml file (e.g. Gazebo)
  • is supported by the ros_buildfarm
  • highly modular architecture which enables / encourages implementing plugins externally and many are being developed by external people which is great: bazel, bundle, cargo, gradle, lcov-result
  • using more modern tools, e.g. pytest including several of its plugins to run Python tests
  • being actively maintained since it is the default build tool of ROS 2

Features are simply being developed on demand so whenever there is a use case which needs something. For many use cases the current state works pretty well and there is no list of features we are planning to work on soon. But as always please feel free to contribute whatever features you consider necessary / important / valuable.