Building "hybrid" ROS1/ROS2 metapackages

Trying to turn my project lanelet2 into a hybrid ROS1/ROS2 package (one that can be used in both ROS versions) I ran into some troubles.

The problem is migrating the metapackage lanelet2, because of the inconsistent treatment of metapackages between ROS1 and ROS2. Imho it would make sense to make the package conditionally depend on catkin or ament_cmake, depending on the value of ROS_VERSION, so that the package.xml essentially looks like this (real file is here):

  <buildtool_depend condition="$ROS_VERSION == 1">catkin</buildtool_depend>
  <buildtool_depend condition="$ROS_VERSION == 2">ament_cmake_core</buildtool_depend>
  <!-- exec_depends on the other packages go here... -->
  <export>
    <build_type condition="$ROS_VERSION == 1">catkin</build_type>
    <build_type condition="$ROS_VERSION == 2">ament_cmake</build_type>
    <metapackage/>
  </export>

However this produces warnings with catkin_pkg in both ROS1 and ROS2, because the package.xml no longer complies with REP 149 since other buildtool_depends than catkin are not allowed.

So what is the best solution here?

I could:

  1. Live with the warnings, but that is obviously not ideal
  2. Try to get a patch into catkin_pkg to tolerate conditional ament dependencies, but then REP 149 is still not followed
  3. Leave away the metapackage tag (as suggested for ROS2). But afaik ROS1 still relies on it, e.g. for building the package documentation

A question like this seems more fitting for ROS answers than for ROS discourse.
http://wiki.ros.org/Support

I was torn between opening an issue in catkin_pkg, posting it on ROS answers and posting it here. I chose this because I think there is no clear, simple answer to my problem. There are multiple options to solve this and as I see it, they would all involve changing something in ROS(1/2). Or the decision to not support my use case at all.

But if this is the general opinion, I’ll be happy to move this to ROS answers.

As indicated in the docs metapackages are a catkin specific construct which only provided a subset of the functionality of a package. This concept was a legacy from rosbuild era. In ROS 2 we no longer have a special case for metapackages, they are just regular packages without contents. If you want a fully dual-compilable package the quickest approach will likely be to do the same in the ROS 1 version.

If you need some help getting that to work I’d suggest following up on https://answers.ros.org

So that means you are suggesting option 3. Then let me rephrase my question: Is there any notable downside of not using the metapackage tag for indicating a collection of packages released within ROS1?

As an example it seems to me that the wiki is relying on it to display the packages of a stackage. And my understanding is that bloom makes use of it too.

Yes, that’s what I’m suggesting.

There should be no significant downsides, it will just be a package. But the concept of the groupings captured in a different way than just dependencies doesn’t propogate to any other systems that we’re interacting with.

The wiki renders the legacy stack style lists based on the metapackage dependencies, and bloom validates the metapackage restrictions if it’s declared. Bloom also automatically adds the equivalent of <architecture_independent/> tag for metapackages which you should probably add if you’re package will remain without any binary content.

Ok, thank you for clarifying!