I think what he’s referring to is that so much of ament_cmake is just a wrapper for standard CMake practices. And that it is somewhat confusing for someone coming from a CMake background who is used to doing things manually.
E.g. Why should I use ament_export_targets and ament_export_dependencies? What are these doing that I can’t do myself as a CMake developer?
I suppose the answers are along the lines of:
- It removes a lot of boilerplate
- It provides a degree of consistency across ROS packages
- It reduces the barrier to entry for new people
- Some of the things it replaces are fairly complex and impractical/impossible to write manually
As someone who is certainly not an expert in CMake, I find it simultaneously confusing and helpful. On the one hand there are all these functions that “just work” and you have to know to use that are different to the other 99% of CMake projects out in the wild. On the other hand, having fumbled around to implement them manually in other projects, it’s very nice to have a system that “just works”.
As I mentioned in another thread we are transitioning some libraries from normal CMake to ROS/ament. Using macros to maintain both systems at once (so we can build on our existing non-ROS platforms) is a pain, but we generally feel that if we had the option to only use one or the other, we’d take the convenience of ament.