Bridge generates and compiles code for all ROS 2 interfaces, even the ones without ROS 1 counterpart

[oKermorgant]

Feature request

Feature description

While compiling the bridge in order to use custom messages, I noticed that all existing ROS 2 interfaces are used to generate cpp files.

This leads to potentially much more code gen and compiles than what should be required.
After a look into ros1_bridge.generate_cpp it seems all the info is available to only generate the relevant bridges.

Maybe there is a reason all ROS 2 interfaces are associated with generated files, but it leads to many files such as:

// include ROS 1 services
// nothing
// include ROS 2 services

namespace ros1_bridge
{
// some FactoryInterface that may never be used?

Implementation considerations

Modifying the generator script is not enough as ROS 2 interfaces (and ROS 1 ones as well) are searched for at two different places / steps:

• in the ros1_bridge Python module, to generate the code
• in CMakeLists.txt, to find_package() all these.

Besides, there is no need to find_package() the ROS 1 messages, as they are header-only. Only setting up the correct include paths should be enough to use them in the generated code.

Small draft

A quick draft of the considered implementation gives the following results.

Some stats on my setup (thanks to ros1_bridge Python module) with ROS 2 humble (from binary) + ROS 1 Debian

Interface	How many	Across # packages
ROS 1 messages	172	9
ROS 1 services	11	4
ROS 2 messages	454	61
ROS 2 services	187	61
Common messages	135	9
Common services	9	4

Time comparisons:

Approach	Generated files	time CMake	time make -j4 user	time make -j4 real
Current	761	13.9 s	64 m	21 m
Proposed	164	7.5 s	25 m	7 m

[mjcarroll]

Great results! Can you open a pull request with your proposed implementation?

[oKermorgant]

Hi,

Sure, I am testing the approach right now because it relies on a small hack.

I'll also include white / black lists of packages at compile time. This is done in the same parts as the ones checking for relevant packages anyway.

As I understand this package will not be distributed as binary anymore so users can compile it according to their needs.