[question] Conan 2.0 Recommended Way to Integrate with CMake to Consume Packages?

[ridler77]

CMake Integration 2.0 Best Practices to Consume Packages?

I'm not concerned with building my own package, but consuming dependencies fetched / built with Conan into my projects. I find navigating the docs to be a bit confusing trying to parse out which is the preferred way to integrate Conan package management (but not creation yet) into our Cmake builds.

I use find_package(lib) but don't mind a line in our top level CM.txt pulling in Conan integration. I need Release / Debug / RelWithDebInfo builds on both Windows and Linux but no cross compiling.

The documentation is unclear about the preferred way to integrate with CMake. There is CMakeDeps, CMakeToolchain, CMake, and cmake_layout. How are they recommended to be used together? If I understand correctly, CMakeDeps makes the FIndXXX.cmake files, CMakeToolchain makes presets and cmake_layout creates Release/Debug folders for Linux multi-config?

So what is the preferred way Conan and CMake compiler settings are shared?
How does conan.tools.cmake play with the cmake-conan integration?

We are migrating to Conan 2.0 and now is a good time to rethink our integration and use best practices.

I successfully used conan.cmake in 1.x by creating a conan_integ.cmake in my top level CML.txt directory that used conan.cmake and scripted the following steps:

conan_cmake_autodetect(AUTO_SETTINGS)
conan_cmake_lock_create( ... )  # generated a derived lock file using auto-detected settings and base lock file
conan_cmake_install( ... )
update CM Module and Prefix paths to find generated conan files

My developers are used to doing the following:

cd project_top_level_CM.txt_folder
mkdir build && cd build
cmake -G "Visual Studio xxx" ..    or cmake -DCMAKE_BUILD_TYPE=Debug ..

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[ridler77]

I should add, while transparent conan integration is really nice, having them call conan install isn't the end of the world. But how do you ensure the profile used matches the cmake settings?

And command lines start to get really clunky conan install -of build -pr profile -l lockfile && cmake -B build -S . -profile ....

[memsharded]

Hi @ridler77

There are 2 different approaches:

• Conan driven approach. Mostly conan install + cmake --preset conan-default
• CMake driven approach. Using new Conan 2 cmake-conan integration using dependency providers: cmake -S . -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=conan_provider.cmake -DCMAKE_BUILD_TYPE=Release or even better, using a preset that defines the CMAKE_PROJECT_TOP_LEVEL_INCLUDES to inject the provider. With this new approach, no changes at all are needed in the CMakeLists.txt, everything happens externally in the dependency provider.

The first approach is the "canonical" one, we use thorougly in our docs, from the beginning https://docs.conan.io/2/tutorial/consuming_packages/build_simple_cmake_project.html. The second approach is there for users that really want a transparent integration, typically developers complaining about having to use a terminal. We think that the first approach has generally more advantages, but if you are interested in the second one with cmake-conan, please have a look to the updated readme in https://github.com/conan-io/cmake-conan