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 useCMakeDepsif your dependencies were not packaged to support that.The reason is simple:
find_packagerequires 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_packagein 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 theCMakeDepsgenerator, based on the information in thepackage_infomethod 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_infomethod of the recipe for that library.This is why you can't decide not to use
CMakeDepsunless 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.