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
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 onlybuild_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.
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.
