I'm looking at migrating to conan 2.0 and using the newer generator CMakeToolChain
without CMakeDeps
so the CMake config files I've already created are used. Seems like it should be doable even though I know (for at least conan.io), it's actively discouraged:
Unfortunately that documentation doesn't mention the corresponding changes needed in CMakeToolchain generator so that cmake would know where to look in the conan cache for the config files of the installed package. The default toolchain file in hello
(I'm using modified versions of say
and hello
from the conan tutorials here adds these paths):
list(PREPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR} )
list(PREPEND CMAKE_LIBRARY_PATH "/home/raptor/.conan2/p/say8a68f1d877fb8/p/lib")
where CMAKE_CURRENT_LIST_DIR
is build/Release/generators
where the toolchain file is located. With only those paths, cmake can't locate the config file (i.e. /home/raptor/.conan2/p/say8a68f1d877fb8/p/lib/cmake/say/say-config.cmake
, package name is say
) of the package in the conan cache.
How would I configure the Toolchain generator to look in the conan cache? Maybe a separate, but closely related question is how would this would if the package was in editable mode?
I think you've misunderstood what the documentation was trying to say about disabling
CMakeDeps
. You as the consumer of existing packages cannot choose to not useCMakeDeps
if your dependencies were not packaged to support that.The reason is simple:
find_package
requires CMake config files, yet many libraries do not create such config files as part of their build (e.g. because they're using another buildsystem that doesn't support it out-of-the-box), or they create them incorrectly (e.g. config files with absolute paths, not mentioning all dependencies, ...).So in order to support finding all dependencies via
find_package
in CMake projects regardless of what buildsystem the dependencies are using conan by default generates the config files for all packaged libraries on the fly via theCMakeDeps
generator, based on the information in thepackage_info
method of the recipe of the dependency.What the documentation was trying to say is that in the case that you package a library that does in fact generate correct CMake config files you can tell conan not to generate config files for this library by using
in the
package_info
method of the recipe for that library.This is why you can't decide not to use
CMakeDeps
unless all of your dependencies are shipping their own CMake config files and did correctly specify that they do in theirpackage_info
. In case they do everything is handled transparently and you do not need to make any changes to the recipe of the consuming project.Similarly, whether a package is in editable mode or not is also transparent for consumers, so this also does not require any changes to the recipe of a consuming project.