Investigate proposed alternatives to the existing message generation pipeline.

[maspe36]

In this months WG meeting, I discussed some painpoints with our current message generation pipeline, and some potential alternatives or changes.

The Problem

Rust does not have a stable ABI, and wants to compile all of the source code and dependencies source code, when compiling a crate. This is fundamentally what pushes us to have such a complex message generation pipeline.

Potential Solutions

I have some ideas that may help alleviate some of this complexity. These ideas are not listed in any order of preference.

Automatically upload ROS 2 messages to crates.io as semver'd packages.

Cargo bakes in semver for crates, but thankfully all ROS 2 message packages have semver versions. Perhaps we could automatically generate and upload crates when new versions of ROS 2 message packages have been published. If we are able to have letters before numbers, then we could in theory have versions like version = "jazzy.*", in our Cargo.toml files. This would alleviate some complexity when it came to upstream message packages, but doesn't change the user story for custom message packages.

Leverage a crate for "plugins"

The abi_stable seems to provide some Rust-to-Rust FFI plugin system. If memory serves this is similar to what we do for rclcpp messages where building the message package, generates a shared library, that downstream packages then dynamically link to.

Restricting a ros2 workspace to have a single cargo workspace

The additional constraints that a cargo workspace provides would potentially allow us to do things like generating message source code on demand from a build script. Of course, this reduces the flexibility of how an end user could organize their source code.

Collecting all upstream ROS 2 messages in a single crate gated with cargo features

This is not my idea, this is from @esteve. Tracking issue for this idea at #394.

---

None of these ideas are perfect, and we have still only done a very high level investigation into all of them. While this investigation is on going, we are in parallel working to improve documentation for our existing message generation pipeline #401.