environment vs. hook artifacts during colcon+ament build

I use the output of the colcon build tool to create large workspace build artifacts ('bundles') for distribution.

When creating ROS1 artifacts, package.dsv references files in the share/<package>/hook directory contains the expected scripts - these modify CMAKE_PREFIX_PATH, ROS_PACKAGE_PATH, etc. appropriately.

When creating ROS2 artifacts, package.dsv references the contents of share/<package>/hook and share/<package>/environment. I assume that hook is managed by colcon, and environment is managed by ament. It seems like only the latter is necessary - these are what are distributed by ROS2 debs.

I discovered an issue recently - since the colcon hooks modify CMAKE_PREFIX_PATH for ament packages (inappropriately?), this actually breaks my build of ros1_bridge, since catkin_find-related code used in that package will now also pick up ROS2 message packages (https://github.com/ros2/ros1_bridge/blob/master/ros1_bridge/__init__.py#L246).

Should I disable hook generation (or delete them after the fact?) for ROS2 builds and rely on the environment files? Why do colcon workspaces end up with both, redundant and somewhat inconsistent sets of environment/hook extensions?

Asked by paulbovbel on 2022-09-23 14:44:53 UTC

Comments

Just so I understand correctly - the actual problem here is that the ROS 2 packages are showing up in ros1_bridge's ROS 1 package discovery because of CMAKE_PREFIX_PATH?

Asked by cottsay on 2022-09-26 11:14:26 UTC

My problem was that catkin_find was discovering ROS2 packages, butI found the source of all my woes, and it turns out it has nothing to do with CMAKE_PREFIX_PATH, but rather that a stray .catkin file was being created at the root of my ROS2 distribution.

Asked by paulbovbel on 2022-09-28 19:04:55 UTC

It turns out my problem is actually due to https://github.com/BehaviorTree/BehaviorTree.CPP/blob/master/package.xml#L33.

I use colcon to build an entire ROS2 distro from scratch, overlaid on top of a ROS1 distribution. This includes a galactic ros_environment that sets ROS_VERSION=2. Even though behaviortree_cpp_v3 declares a build dependency on ros_environment, and colcon properly builds ros_environment before trying to build behaviortree_cpp_v3, it seems that colcon processes behaviortree_cpp_v3/package.xml up front, when ROS_VERSION=1, and ends up running a catkin task type for this package rather than ament_cmake.

Asked by paulbovbel on 2022-09-28 19:05:09 UTC

Even though the rest of the distribution is built properly, this one failure slipped by and created the .catkin file, causing ros1_bridge to 'discover' ROS2 message packages as ROS1 message packages via catkin.find_in_workspaces, and causing all sorts of havoc. The .catkin file was hard to track down because it's empty, and wasn't showing up when I ran diff to compare a working build against the broken one.

Asked by paulbovbel on 2022-09-28 19:06:48 UTC

Unless I can figure out how to resolve this, I'll just be using my fork here (https://github.com/paulbovbel/BehaviorTree.CPP/commit/27262f9db549d4106326311b28f30a40978ab678)

Asked by paulbovbel on 2022-09-28 19:07:43 UTC

environment vs. hook artifacts during colcon+ament build

Comments

Answers