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.
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.
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.
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?
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).
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?
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. GitHub - 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.
For now I’ll focus on other aspects of the binding while the dust settles.