I’m actually a big proponent of the idea to backport ament to ROS 1 (and maybe even some ament features to catkin), because I think it lets people take a step toward ROS 2 without jumping in with both feet while simultaneously gaining some benefits (assumption is ament is better than catkin, which I do believe). Also, it lets developers more easily support ROS 1 and ROS 2 at the same time (same branch). This is especially attractive for packages which are mostly ROS agnostic, e.g. class_loader or the new rviz_rendering package.
I don’t want to hijack the thread, but just to expand on what @dirk-thomas said, I collected a list of things that would need to be addressed a while back:
- support building packages with the
build_typeofament_cmake(catkin_make_isolatedandcatkin_tools)- make the
setup.*shfiles (which are installed to the install folder’s root) source both catkin and ament setup files and environment hooks (currently only handles catkin stuff) - address conflicts which may occur when
ament_cmakeuses Python3, but the ROS 1 packages and the build tool in ROS 1 (catkin_make_isolatedorcatkin_tools) uses Python2
- make the
- release all packages in the
ament/ament_cmake,ament/ament_lint, and possiblyament/ament_indexrepositories - deal with
ROS_PACKAGE_PATHversusament_index- for details about
ament_indexsee: https://github.com/ament/ament_cmake/blob/master/ament_cmake_core/doc/resource_index.md - not sure what needs to be done here, maybe just add ament packages to the
RPP - otherwise support would be needed in
roslib,rospack, andpluginlib(maybe other places) for theament_indextoo or some other solution
- for details about
- consolidate
ros-infrastructure/catkin_pkgandament/ament_package- not strictly needed, but would prevent us from having two implementations of
package.xmlparsing
- not strictly needed, but would prevent us from having two implementations of
- deal with any issue that arise and update documentation so people are aware of the changes