ros2 / ros_workspace Goto Github PK

Replace the hacky calling cmake install with real ament_cmake environment hooks.

Targeted for post-ardent.

Currently, there are a number of packages in ROS 2 which are built from sources outside our control. These packages still install themselves into the ROS prefix (/opt/ros/$ROS_DISTRO/) but don't provide any environment hooks to ensure that their executables are put onto PATH and their libraries are added to LD_LIBRARY_PATH, or other platform equivalents.

To overcome this issue for debian packages in early releases of ROS 2, this workspace package added some environment hooks unconditionally putting the necessary paths on LD_LIBRARY_PATH.

Packages benefiting from these hooks in ROS 2 bouncy (packages which have shared libraries in /opt/ros/bouncy/lib but no environment hook setting up the library path for themselves)

• ros-bouncy-console-bridge
• ros-bouncy-examples-rclcpp-minimal-composition
• ros-bouncy-fastcdr
• ros-bouncy-fastrtps
• ros-bouncy-orocos-kdl
• ros-bouncy-osrf-testing-tools-cpp
• ros-bouncy-rclpy
• ros-bouncy-resource-retriever
• ros-bouncy-rviz-common
• ros-bouncy-rviz-default-plugins
• ros-bouncy-rviz-rendering
• ros-bouncy-urdfdom

Some of these packages are ours and we should determine whether setting hooks for them is needed.

A number of packages that have needed this treatment are moving into _vendor packages which would potentially be a better home for these hooks.

For the remaining packages and future packages that can't provide their own hooks, is it worth populating the workspace with hooks for the default executable and binary paths so that no matter what further packages are installed the ROS prefix is usable?

Hi,
If I understood properly, this package takes care of installing the /opt/ros/distro/(local_)setup.xx scripts. These files template are located in the ament_package and are specialized during build by a ament_cmake_core script. Both of those packages are build dependencies.

Now, the /opt/ros/distro/(local_)setup.xx scripts make use of the Python3 interpreter (see here and onward) which isn't an exec-dep and may very well not be installed resulting in,

/usr/bin/env: ‘python3’: No such file or directory
error: unable to find fallback python3 executable

The latter message coming from the local_setup.xx script.

So, shouldn't this package have an <exec_depend>python3</exec_depend>?

There is no top level LICENSE file
The MIT license makes sense for a project like this.

Steps to reproduce the issue:

apt-cache show ros-foxy-ros-workspace | grep-dctrl --no-field-names --show-field=Depends --field=Depends 'ros-foxy-ros-environment'

Expected behavior:

ros-foxy-ros-workspace has ros-foxy-ros-environment in its Depends.

Actual behavior:

ros-foxy-ros-workspace does not have ros-foxy-ros-environment in its Depends.

Additional information:

https://github.com/ros2-gbp/ros_workspace-release/blob/debian/foxy/focal/ros_workspace/debian/control