Some concerns about building zenoh-bridge-dds as a ROS package

[YuanYuYuan]

Hi, @JEnoch ,

Recently I encountered a compilation error while building zenoh-bridge-dds with colcon.
Then I realized that this problem is coupled with colcon-ros-cargo and cargo-ament-build.

The team ros2-rust suggests users from Rust world using either colcon-ros-cargo + cargo-ament-build or
[colcon-cargo]. The former can be built by giving package.xml in addition to Cargo.toml. The latter one
can be applied on pure Cargo.toml. But building zenoh-bridge-dds still needs custom command to build since
it can't build zenoh-bridge-dds with the zplugin dependency.

And here are some observation when using colocon to build the zenoh-bridge-dds

Setup a workspace

mkdir -p workspace/src
git clone https://github.com/eclipse-zenoh/zenoh-plugin-dds workspace/src/zenoh-plugin-dds

1. Native colcon: passed, which perfectly follows the custom command written in CMakeLists.txt.

colcon build

2. colcon-cargo: passed, which actually invoke the way same as 1.

pip3 install --user --upgrade git+https://github.com/colcon/colcon-cargo.git
colcon build

3. colcon-ros-cargo + cargo-ament-build: failed since it cannot detect the package properly. (Note that we used our patched version here.)

pip3 install git+https://github.com/jerry73204/colcon-ros-cargo.git@merge-colcon-cargo   # this patch is for cargo workspace resolvement
cargo install --git https://github.com/jerry73204/cargo-ament-build.git                  # this patch is to prevent removing non-existing Cargo.lock
colcon build

First of all, this hasn't be a bug except users having method 3 installed. (Unfortunately, I'm one of that group...)
However, the problem of method 3 is caused by the location of CMakeLists.txt and package.xml.
A classical ros2 workspace containing packages look like this.
It may be better to have CMakeLists.txt and package.xml written for one explicit package instead of a workspace.
So I propose moving these two files into zenoh-plugin-dds/zenoh-bridge-dds and making some tiny changes on the path of the manifest.
I tested this proposal and ensured that all three methods above could work well.

PS. Since colcon-ros-cargo is still not mature, I wouldn't recommend using it. But it can be a good tool to build Rust code as ROS2 package without handcrafted CMakeLists.txt.

[JEnoch]

My first concern with such a change is the behaviour on ROS2 buildfarm (build.ros2.org.
I'm not sure it has colcon-ros-cargo + cargo-ament-build installed since, as you mentionned, it's still not mature.

Note that those builds are currently failing anyway, since zenoh requires a more recent Rust version than the default Debian's one available on the buildfarm... But hopefully, they will upgrade soon.

Then, I'm also wondering:
what's the benefit for ROS2 users to build zenoh-bridge-dds via colcon vs. just install the latest released binary via our Debian repo ?
Moreover, building it directly on the robot that might be just a RaspPi takes log of time, CPU and disk/SDCard (+2GB!).

[YuanYuYuan]

Thanks for your comments! The issue is moving the CMakeList.txt and package.xml into zenoh-plugin-dds/zenoh-bridge-dds would affect
the behavior on ROS2 buildfarm or not. However, regarding the builds on top of it still don't work, then let's postpone it.

BTW, let me answer the questions above:

1. I really agree with your point about compiling problems on RPi. We also use cross-compiling as an alternative.
2. Since our lab research focuses on autonomous vehicles, our machine is just powerful enough. (luckily?)
3. I didn't directly install through Debian packages just because my OS is not Debian/Ubuntu. As 2. stated, we'd like to compile it from the source.
4. We use colcon to manage the building in order to simplify the building steps. Our other applications like Autoware are also based on colcon.
   However, I found that zenohd doesn't provide colcon build.
   As a workaround, I also write a script for installing zenohd particularly. So..., we still can't encapsulate them all inside the ROS colcon world.