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/b...).
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?
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 ofCMAKE_PREFIX_PATH?My problem was that
catkin_findwas 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.catkinfile was being created at the root of my ROS2 distribution.It turns out my problem is actually due to https://github.com/BehaviorTree/Behav....
I use colcon to build an entire ROS2 distro from scratch, overlaid on top of a ROS1 distribution. This includes a galactic
ros_environmentthat setsROS_VERSION=2. Even thoughbehaviortree_cpp_v3declares a build dependency onros_environment, and colcon properly buildsros_environmentbefore trying to buildbehaviortree_cpp_v3, it seems that colcon processesbehaviortree_cpp_v3/package.xmlup front, whenROS_VERSION=1, and ends up running acatkintask type for this package rather thanament_cmake.Even though the rest of the distribution is built properly, this one failure slipped by and created the
.catkinfile, causingros1_bridgeto 'discover' ROS2 message packages as ROS1 message packages via catkin.find_in_workspaces, and causing all sorts of havoc. The.catkinfile was hard to track down because it's empty, and wasn't showing up when I randiffto compare a working build against the broken one.Unless I can figure out how to resolve this, I'll just be using my fork here (https://github.com/paulbovbel/Behavio...)