Open oKermorgant opened 1 year ago
Great results! Can you open a pull request with your proposed implementation?
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.
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:
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:
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
Time comparisons:
time CMake
time make -j4
usertime make -j4
real