ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS2 (cross) compilation: how to separate host tools, target binaries and graphics tools

There are ~300 packages in the ROS2 distro. Some of them are host tools, like ament (no need to deploy on the target system), some are binaries installed on the target (libs etc.) and some are visualization tools like rviz (need graphics support, can stay on the host as well).

I build ROS2 for VxWorks and would like to cross-compile only packages that go to the embedded target.
I think such a split could be useful for the native compilation as well, e.g. when I don’t want to install everything on my target system.

Is it a way to separate them while building ROS2? Something like:
colcon build --host-tools (native build)
colcon build --target-binaries (cross or native build)
colcon build --graphic-tools (native build)

@dirk-thomas, probably you are the best person, who knows the answer :slight_smile:

Kind Regards,
Andrei

The packages don’t expose that kind of information to be selected in an automated fashion. Atm you will need to populate the workspace for each environment by hand.

Is it any algorithm I can apply which helps me to filter out e.g. all host tools?
e.g. colcon build --packages-up-to ```colcon list --packages-select-regex ament*`` ?

It will probably help to think about packages as <build_depends> (not “host tools”) vs <exec_depends>/<run_depends> for the workspace. You need the ament packages as build_depends but they are not needed as a runtime dependency.

“Graphic tools” is meaningful to us to think about, but it doesn’t mean anything in particular in terms of the packages or the code involved. ros-core and ros-base do not have any GUI dependencies by definition, as per REP 2001. So, it may be useful to think about targeting one of these variants for your builds, if you are trying to avoid GUI tools.

rospkg, which is used by colcon and rosdep to determine dependencies of packages, is able to determine these different types of dependencies, and so may be a useful tool in figuring out what portions of your produced install are actually necessary to go to the target system.

An idea - you could use rospkg to determine, for a given metapackage (e.g. ros-core), what are all the recursive dependencies, figure out which ones are only build_depends, then create a workspace containing those, with all the run_depends in a second workspace that layers on top. This could theoretically produce something like a “runtime only” install dir (though it may depend on the setup.sh scripts from the “build tools” workspace, i’m not sure)

I think it is a good approach. I have also thought about <exec_depends> / <run_depends>. Based on package.xml description
Execution Dependencies specify which packages are needed to run code in this package.
It means that <exec_depends> can be inside any package. However, it should be at least two non-overlapping entities, e.g. tools should not overlap with the target binaries.
Thanks for pointing me out to the REP-2001. I have also found this one: REP-2005 with other categories. It is more granular, however also a bit of a mix of both. I’ll look at what packages have <exec_depends> tag and what packages are marked as <buildtool_depend>.

rospkg is not used in ROS 2. catkin_pkg is used to parse package manifests and determine the dependencies.

Please see REP 149 which describes the various dependency tags. While tool usually indicates a dependency that needs to be satisfied on the platform building I don’t think this will give you complete / correct enough information to generate these sets automatically.

My mistake - but it is used by rosdep which is used in workflows around ROS 2.

I grep for <buildtool_depend> in dashing and it gave me completely at some places bizarre results.

grep -nr “<buildtool_depend>” * | cut -f 2 -d ‘>’ | cut -f 1 -d ‘<’ | sort | uniq

ament_cmake
ament_cmake_auto
ament_cmake_core
ament_cmake_export_dependencies
ament_cmake_python
ament_cmake_ros
ament_cmake_test
ament_copyright
ament_index_python
ament_lint_cmake
ament_package
catkin
cmake
connext_cmake_module
cyclonedds_cmake_module
@dep
eigen3_cmake_module
fastcdr
fastrtps
fastrtps_cmake_module
opensplice_cmake_module
pkg-config
python3-catkin-pkg-modules
python3-empy
python-catkin-pkg
python_cmake_module
rosidl_cmake
rosidl_default_generators
rosidl_generator_c
rosidl_generator_cpp
rosidl_parser
rosidl_typesupport_connext_cpp
rosidl_typesupport_fastrtps_cpp
rosidl_typesupport_opensplice_cpp
rti-connext-dds-5.3.1

e.g. fastcdr comes from
ros2/rosidl_typesupport_fastrtps/rosidl_typesupport_fastrtps_c/package.xml:13: <buildtool_depend>fastcdr</buildtool_depend>
ros2/rosidl_typesupport_fastrtps/rosidl_typesupport_fastrtps_cpp/package.xml:13: <buildtool_depend>fastcdr</buildtool_depend>
and it is no way that the fastcdr is a build tool.

Build Tool Dependencies specify build system tools which this package needs to build itself. Typically the only build tool needed is catkin. In a cross-compilation scenario build tool dependencies are for the architecture on which the compilation is performed.

@dirk-thomas, some of the packages have a cmake as a buildtool_depend

razr@windix:~/ros2_foxy/src$ grep -nr “<buildtool_depend>cmake<” *
ament/ament_cmake/ament_cmake/package.xml:10: <buildtool_depend>cmake</buildtool_depend>
ament/ament_cmake/ament_cmake_core/package.xml:19: <buildtool_depend>cmake</buildtool_depend>
eclipse-cyclonedds/cyclonedds/package.xml:14: <buildtool_depend>cmake</buildtool_depend>
eProsima/foonathan_memory_vendor/package.xml:13: <buildtool_depend>cmake</buildtool_depend>
osrf/osrf_testing_tools_cpp/osrf_testing_tools_cpp/package.xml:12: <buildtool_depend>cmake</buildtool_depend>
osrf/osrf_testing_tools_cpp/test_osrf_testing_tools_cpp/package.xml:12: <buildtool_depend>cmake</buildtool_depend>
ros2/orocos_kinematics_dynamics/orocos_kdl/package.xml:13: <buildtool_depend>cmake</buildtool_depend>
ros2/orocos_kinematics_dynamics/python_orocos_kdl/package.xml:13: <buildtool_depend>cmake</buildtool_depend>
ros2/urdfdom/package.xml:20: <buildtool_depend>cmake</buildtool_depend>

Since the whole system is a CMake build based, I’m wondering whether it makes sense?