[feature] Add AmentDeps generator for ROS2 support in colcon builds

[danimtb]

Changelog: Feature: Add Ament generator for ROS2 support in colcon builds
Docs: missing

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[memsharded]

Where are these files coming from?
It is a bit surprising having to embed all this stuff for this to integrate with ros

[danimtb]

The templates can be found at https://github.com/ament/ament_package

Probably some files are not completely necessary, but I'd rather play safe for the moment and mimic the Ament behavior.

[memsharded]

I'd prefer not to include this by default if we don't really understand what they are doing and we can take ownership of them.

For example other ament package like this one https://github.com/ament/ament_cobra, doesn't seem to include these scripts. What are they doing? are they really necessary?

[alsora]

Most of these scripts are automatically generated when building a package with the colcon and ament tools, so you won't find them in the source code.
The package.xml is the only exception (this is needed for building and it's then copied into the install folder)

[alsora]

@danimtb what's the purpose of this generator?

When building a ROS 2 package, all this is not necessary (the ROS package will already contain a package.xml, and calling colcon build will result in all these files being created in the install folder).
It looks like this generator can be used to "augment" a non-ROS package in a way that mimics the layout of ROS packages.

[memsharded]

Thanks for your feedback @alsora

The goal of this integration is to allow colcon builds to use any existing Conan packages, as automatically as possible.
In this way, ROS packages can use any existing package in ConanCenter, or even proprietary packages in your own servers.

The idea is that a conan install ... -g=AmentDeps will create all the necessary files to locate and use the required libraries in a colcon build, in the same way that CMakeDeps can generate all the xxx-config.cmake files on the fly, or MSBuildDeps can generate necessary xxxx.props files to be used by VS

[alsora]

Thanks for the explanation, but I don't think you need any of this.
You can already build almost all C++ ROS 2 packages using colcon build without a dedicated generator.

Colcon (or ament) won't check for the existence of any of those files that you are creating with the generator while building other packages.

For example:

• resource index files (https://github.com/conan-io/conan/pull/17055/files#diff-4e554ff061bbe751e8b8effd735c4d283c3b48fc15695e13ff73a43d8649d92aR783-R785) are usually used by runtime introspection tools to find ROS packages.
• setup, package and environment files (https://github.com/conan-io/conan/pull/17055/files#diff-4e554ff061bbe751e8b8effd735c4d283c3b48fc15695e13ff73a43d8649d92aR787-R802) are used by the users that want to expose a package to the system

When building package X, a ROS 2 C++ package, this will have a package.xml listing its direct dependencies.
Colcon will parse the package.xml with the only purpose of definining the order of build in case a workspace contains multiple projects.
Then it will invoke CMake, which will try to find the direct dependencies via a standard find_package CMake function call.

If anything, the setup files I mentioned above would be useful for a ROS 2 VirtualEnvGenerator, but that seems a different topic.

The cmake_find_package or cmake_find_package_multi generators should be sufficient to allow the build of a package to find dependencies built via Conan.

[danimtb]

Hi @alsora and thank you very much for your comments above.

Indeed, many of the files included in the generator are not needed as those are generated by Ament itself. They were added in an early stage of the development of the generator, so I have removed them in the latest commits.

Let me explain a little bit the purpose and how this generator is working at the moment.

The goeal of the generator is to make the Conan installed dependencies available to a ROS2 package that has external dependencies, like boost for example.

So, the way this works is by collecting the required conan dependencies from a conanfile.txt and creating "fake" packages in the colon workspace for only the direct dependencies and then placing the CMake find package files generated by Conan into the install folder in the appropriate path.

Let's take the example of a ROS2 package called "consumer" that depends on Conan boost package. This AmentDeps generator will create a "conan_boost" package in the workspace and place the CMake find package files of boost and its transitive dependencies generated by conan into the path install/conan_boost/share. This is done this way, so when you invoke colcon build (as "consumer" package has a <depend>conan_boost</depend> in its package.xml file), then the CMAKE_PREFIX_PATH of conan_boost is injected automatically by colcon on the build and the cmake find package files of conan are found without the need of doing anything else.

I have prepared an examples repo with this case at https://github.com/danimtb/ros2-examples?tab=readme-ov-file#conan_install_ament_example for better understanding.

Why do we have this <depend>conan_boost</depend> in the "consumer"'s package.xml? This is because of the automatic CMAKE_PREFIX_PATH append by colcon but also because we have prepared a rosdep integration for conan that will avoid the need of having a conanfile.txt and the user calling conan install explicitly and use rosdep install instead (see more here: https://github.com/danimtb/rosdep/blob/feature/conan/src/rosdep2/platforms/conan.py and here: https://github.com/danimtb/rosdistro/blob/feature/conan/rosdep/conan.yaml)

At this point, we have some questions so we can move this forward:

• Would it be better to avoid this "fake" conan-ros generated packages approach and just let the user set CMAKE_PREFIX_PATH to the Conan install folder? Or, is there any other way that we can set this CMAKE_PREFIX_PATH for the user? A file that colcon recognizes or similar?
• Do you think the rosdep integration approach will be something nice to have for ROS users?
• Also, as the Conan installed package's libraries live in the conan cache, it would be nice also to integrate the environment setup into the ros install/setup.bash mechanism so executables that have shared dependencies from conan can find the libraries in te conan cache. Do you know if this is possible? I have experimented a bit with the library_path.dsv file contents and made it work at some time, but maybe there is a cleaner approach.

Thanks again for the feedback, this very appreciated for us as we are not ROS experts 😅