Dependencies for adding Zenoh as a third ROS 2 middleware option

[habby1012]

Context

I'm currently implementing Zenoh as a third ROS 2 middleware option alongside FastDDS and CycloneDDS on the ue4-dev branch, building on the rename refactor in #9711.

Before opening the implementation PR, I'd like to align on two architectural decisions that affect the build system.

Question 1: Rust as a new build dependency

zenoh-c is written in Rust, so building it from source adds a Rust toolchain to CARLA's build-time dependencies. Setup.sh would install the toolchain project-locally so no system-wide Rust setup is required from users.

Rust installation itself is quick, and the zenoh-c / zenoh-cpp build time is comparable to the existing FastDDS / CycloneDDS builds.

Is introducing Rust as a build dependency acceptable?

Question 2: -std=c++17 for the carla_ros2 target

Including zenoh.hxx (the zenoh C++ wrapper) requires C++17.

Proposed approach: scope -std=c++17 to carla_ros2 and carla_ros2_debug targets only by adding it to target_compile_options in LibCarla/cmake/ros2/CMakeLists.txt (L30, L52).

Other targets (libcarla-server, libcarla-client, PythonAPI, UE plugin, etc.) stay at C++14.

This is safe because:

• clang -std= is last-wins, so the per-target flag overrides the toolchain's global -std=c++14 only for the targeted units
• C++14 and C++17 ABIs are compatible when linked into one binary

Fallback: if C++17 is not acceptable, I can implement the middleware using zenoh.h (zenoh-c's pure C API) instead. However, the implementation becomes more verbose — I'd need to manually open/close zenoh handles and free resources for every object, which the C++ wrapper handles automatically.

Is the scoped C++17 bump acceptable?

Next steps

Once both decisions are aligned, I'll open the implementation PR.

Thanks in advance for your time and feedback! @LuisPovedaCano @JArmandoAnaya

[JArmandoAnaya]

Question: Is it strictly necessary to add Rust to the project? The recommendation is to keep third-party dependencies to a minimum unless they are necessary. In that case, we will need to add it in a way that does not complicate the current compilation process for both supported OS (Ubuntu and Windows). If Rust will be necessary as an external dependency, in my opinion, a discussion about the best way to add it to the project is necessary before taking any action.

[habby1012]

Thanks @JArmandoAnaya — I think there are two viable approaches, both produce a static libzenohc.a linked into LibCarla, so end-user runtime is identical to FastDDS / CycloneDDS.

Option A — build zenoh-c from source. Setup.sh installs the Rust toolchain project-locally and runs cargo build. The flow is essentially the same as how FastDDS / CycloneDDS are vendored now. Only difference is adding the Rust toolchain as a build dependency.

Option B — download Eclipse's prebuilt release. Setup.sh wget the official standalone zip from Eclipse Zenoh's GitHub Releases and extracts libzenohc.a + headers project-locally. No Rust toolchain involved. But this would be the first build-time library dependency fetched as a prebuilt binary rather than compiled from source.

[JArmandoAnaya]

Maybe compiling the library is the best option. 🤔

[habby1012]

Thanks @JArmandoAnaya — I understand the concern about adding Rust as an extra build-time dependency.

Would it be acceptable if the Rust toolchain is installed project-locally, used only to build libzenohc.a from source, and then removed at the end of Setup.sh?

I tested this locally. The persistent Zenoh footprint is ~50 MB under Build/zenoh-install, comparable to FastDDS (~45 MB) and CycloneDDS (~15 MB). The temporary Rust toolchain peaks at around ~2 GB during setup, but is removed after libzenohc.a is built.

This would keep Rust as a transient, project-local build dependency rather than a persistent dependency in the CARLA tree.

One quick follow-up: Question 2 above, scoping -std=c++17 only to carla_ros2 / carla_ros2_debug, is still open — any thoughts there, or is it okay to proceed with the scoped bump?

[LuisPovedaCano]

Q1: Rust toolchain:
Between the two options, I'd lean towards Option B (pre-built binary). I understand it would be the first build-time dependency fetched as a prebuilt binary rather than compiled from source, but a transient 2 GB Rust toolchain during setup feels like a significant cost for something that gets thrown away. The official Eclipse Zenoh releases are well-maintained and cover both target platforms, so I think the trade-off is reasonable here.

Q2: C++17:
My concern here is maintainability going forward. The middleware is a build flavour.
If we bump the C++ standard for Zenoh, we'd potentially need to do the same for any future middleware that has similar requirements, and we'd end up with each flavour driving its own structural changes to the build system. That doesn't scale well.

[habby1012]

Thanks @LuisPovedaCano, makes sense. We'll go with Option B and use the prebuilt — no Rust involved at any stage.
And agreed on C++17 — we'll skip zenoh-cpp and go with the pure C API, so carla_ros2 stays on the same C++ standard as the rest of LibCarla.

[JArmandoAnaya]

Please add C++ tests using GTest, similar to the current tests in DDS. Also, run all tests to verify that your refactoring is not negatively affecting the current middlewares.