ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS 2 Conan Integration

Hi everyone,

with this post I would like to start a discussion around one of the challenges that people face when they look into transitioning to ROS 2.

As we all know, ROS 2 is an highly-federated ecosystem of packages and comes with its own build tools and package managers (e.g. colcon).
In my opinion, these tools work great when you are developing a new project from scratch and you want to completely embrace the ROS ecosystem.
On the other hand, if you are in a situation where you already have a large project and you only would like to be able to add ROS 2 to it, the aforementioned tools may not look like the best solution.

To address these issues, in the past few months Eric Riff and I, from iRobot, have developed a set of tools that allow to integrate ROS 2 into Conan, one of the most popular C++ package managers.
If you are not familiar with Conan, I invite you to have a look at the extremely well-written documentation that can be found on their website.

As a quick summary, the Conan package manager is based on the concept of “recipe”, i.e. a Python script that provide instructions for building and packaging a given library. It specifies its name, the version/s, sources and dependencies. It also provides a list of options which can be used to enable/disable functionalities or change certain aspects of the library to be compiled
Some of the great features of this approach are:

  • Recipes allow to easily fetch pre-built packages and use them in your application
  • There is a lot of support for cross-compilation
  • You can pin exact versions of packages
  • Conan is open-source and decentralized, so you can have your own repository of recipes and server of packages

We created a Github repository where you can find some Conan recipes that can be used to build ROS 2 packages, together with an example application that consumes them.

The core of the contribution consists in some base-class recipes that allow to easily write generic ROS 2 recipes.
Then it’s possible to choose any type of granularity: you may have a single recipe that contains all the ROS 2 libraries that you want to use or you may want to separate ROS 2 build tools (ament) from the ROS 2 core libraries (which need to be cross-compiled) and from the developer tools (rviz, rqt, etc).

The approach has still some areas where it can be improved: for example conan recipes require to manually list all the dependencies, which will become very tedious and error-prone the more recipes you have (especially in the extreme case where you may have one recipe for each ROS 2 library)!

We would like to hear feedbacks from the community to be able to improve this infrastructure and, hopefully, to have officially released ROS 2 Conan recipes one day!

Thank you,


:+1: for Conan in general.

I’m wondering though:

How does using Conan support the use-case (requirement? constraint?) you mention specifically (ie: being able to add ROS 2 to it, instead of completely embrace[ing] the ROS ecosystem)?

(I expect you know / have figured that out, but your post seems not to make it explicit)

Another +1 for Conan in general.

1 Like

This is the problem that tools like bloom (bloom - ROS Wiki) and superflore (GitHub - ros-infrastructure/superflore: An extended platform release manager for Robot Operating System) were designed to solve. We have all this information via the package.xml and rosdep, and we use it to create deb and rpm artifacts.

I experimented with generating Homebrew formulae for macOS but it stalled due to the moving target of macOS+homebrew.

If you don’t use a tool like this, then you have to maintain the recipes manually and as you suggested this would be very time consuming.

It seems to me that generating these Conan recipes from bloom and then having aggregating packages to combine them might make sense.

At the very least you could use the same api and logic bloom uses to automate the creation of your recipes, even if you end up grouping things.

In general I’m in favor of using newer tools like Conan, but I do think automating the integration is the most sustainable thing to do, even if it requires a larger initial investment.