Optimize cargo dependency rebuilds/package discovery

[jdiez17]

Hi, thanks for your work on the Rust for ROS2 ecosystem!

I'm running into the limitation described in the README:

Notably, there is quadratic build cost as a function of the dependency chain length. To illustrate this, assume there are packages A, B and C, where C depends on B and B depends on A. If colcon builds this workspace, it builds A first, then B, then C. However, Cargo will also build all the dependencies, i.e., to build B, Cargo will build A again, and to build C, it will build A and B again.

Have you considered setting up a Cargo workspace with all of the Rust packages, so that they can share a build directory, and then install them to the appropriate locations per ROS2 workspace layout?

This also makes it easy to refer to other crates in the workspace without having to add a [patch.crates-io]. You can see an example of this here: https://github.com/raccoon-os/rccn_userspace_ws/blob/master/Cargo.toml.

With this setup, I can run cargo build at the root of the repository and all of the packages are built with a shared build cache. They then just need to be installed to install/pkg/lib etc.

[maspe36]

Hey jdiez17, thanks for the issue and for using ros2_rust!

One of the advantages of ros2_rust is that we have message generation from .msg files (among others). This means we generate a Rust crate per ROS 2 package with .msg files. This generated crate today gets placed in the ROS 2 workspace install/ location. I don't think it would be a good idea to generate crates next to the users source code.

Have you considered setting up a Cargo workspace with all of the Rust packages, so that they can share a build directory, and then install them to the appropriate locations per ROS2 workspace layout?

This is sort of one of the options we've identified. If we can constrain a ROS 2 workspace to one Cargo workspace then yes, we can share build artifacts between crates in the same Cargo workspace. In fact, you may be able to leverage this now, I have yet to investigate the current behavior with that setup.

Unfortunately, this is a very complex topic and an active area of development. It is not easy to blend two different build systems with different philosophical approaches. The tracking issue ros2-rust/ros2_rust#402, has more details and a few other options we are looking at. Any and all help is greatly appreciated!