ROS 2 Conan Integration

Next Generation ROS
,
21

Now that Conan 2.0 is available, and repository/package/CLI support for Conan 1.0 will be eventually sunsetted (at least within the official Conan Center repositories and Artifactory Cloud private respositories), the need to find a new solution for installing conan dependencies within the ROS2 build workflow is upon us. As @RFRIEDM mentions, the cmake-conan wrapper does not support conan 2.0, and based on discussions within the conan slack channel, this was never a recommended approach in the first place.

Has there been any more discussion/thinking by anyone out there around methods to properly support Conan within the context of rosdep to help support the use of conan packages as real ROS2 package dependencies?

It feels like the only two ā€˜properā€™ approaches to supporting ROS2+Conan are to either:

  • Make rosdep understand/support the use of conan packages as package dependencies
  • Package all ROS2 dependencies as conan packages, which has many advantages, particularly the ability to eliminate many arch/distro support limitations (quite the difficult task, if not automated, as mentioned earlier in the thread)

For now, the easiest workaround I can think of (to fill the gap of the cmake-conan solution) is to have some kind of colcon feature/plugin that allows a pre-build hook for invoking conan install for a package before invoking the cmake build process. (Is there any way to run some custom code before "colcon build" runs setuptools? Ā· Issue #633 Ā· ros2/ros2 Ā· GitHub)

Really interested to hear how others out there are handling conan at this point. @alsora has your team made any further progress on this?

2 Likes
22

Iā€™m not very familiar with Conan, but have started to look into it.

Make rosdep understand/support the use of conan packages as package dependencies

Seems possible, I saw that that Microsoft had done something to get it working with vcpkg so its not unreasonable to thing rosdep could work with Conan.

For now, the easiest workaround I can think of (to fill the gap of the cmake-conan solution) is to have some kind of colcon feature/plugin that allows a pre-build hook for invoking conan install for a package before invoking the cmake build process.

I havenā€™t tried yet, but from what Iā€™ve seen in the tutorials, conan install will create a cmake toolchain file which has all the paths to the dependencies. So it should be possible to do conan install and then colcon build --cmake-args -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake? The caveat being that you need a conanfile which includes all the dependencies of your workspace.

23

Correct, mechanically speaking there is no barrier to manually running a conan install and specifying the toolchain file, though you do run into the issue you mention of being limited to using a single conanfile.txt/py for your entire colcon build. With the old cmake_conan helper macros, each individual package could have its own conanfile and have its dependencies installed as part of the CMake configuration stage of the specific package.

That said, there are still other potential issues with conan integration when slapping it on like this, such as rosdep/ament and conan not knowing about overlapping/conflicting dependencies and whatnot, so you have to be a bit careful or you could end up with some tricky problems, especially now that conan2 has removed the CONAN_PKG::pkgname cmake target approach and instead requires plain find_package(pkgname) resolution. Conan relies on the order in which the toolchain file is handled, and which order find_package() will resolve paths in, to make sure that conan packages are found before system packages. I have not investigated the ament side of this equation deeply yet, but I can easily imagine the potential for scenarios where either conan or ament have some of these assumptions violated by the other.

All of that said, since my last post, someone on the conan slack channel shared their approach to implementing similar functionality to cmake-conan for conan2. I havenā€™t tried it yet (still working with conan1), but this might at least allow automatically invoking conan install on a per-package basis without a global conanfile or per-colcon-build-invocation cmake toolchain override.

24

I can probably share the philosophy we use for this kind of thing, or at least how we handle it with python dependencies (of which a lot arenā€™t packaged as debs).

  1. include a library system-wide, via something like py2deb and an apt repo
  2. include a library distro-wide, which we do via colcon support python packages natively. I imagine conan packages are just cmake or make under the hood, so at least cmake packages are relatively easy to add to a distro via bloom.

When integrating 3rd party dependencies, I would prefer to use conan; this would make happy my users in group 1. and, allow me to use a specific version of the library, instead of the one coming with my specific Ubuntu distribution.

  1. include a library on a per-package basis, seems to be the only thing that supports this requirement, at least assuming that the ā€˜specific version of the libraryā€™ youā€™re dependant on isnā€™t useful outside of the package youā€™re working on. This is what we do with python dependencies via GitHub - locusrobotics/catkin_virtualenv: Bundle python requirements in a catkin package via virtualenv (and will need an ament/ROS2 version quite soon). I imagine thereā€™s some cmake magic that could be done to support bundling conan dependencies inside a ROS package at build time as well?

EDIT: apologies, looks like (3) is sort of exactly what GitHub - calebkiage/conan-cmake-toolchain does. Neat!