0

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:

https://docs.conan.io/2.0/reference/tools/cmake/cmakedeps.html#disable-cmakedeps-for-installed-cmake-configuration-files

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?

schrödinbug
  • 692
  • 9
  • 19

1 Answers1

0

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 use CMakeDeps 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 the CMakeDeps generator, based on the information in the package_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

self.cpp_info.set_property("cmake_find_mode", "none")
self.cpp_info.builddirs.append(<path-to-cmake-config-files>)

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 their package_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.

Corristo
  • 4,911
  • 1
  • 20
  • 36
  • I think I'm finally grokking this. How do you specify the ? On a cmake package done correctly (with dependencies) there are a handful of files: the targets file that contains the actual exported targets, the config file that has the `find_dependencies` calls in it, as well a file with version info. In the build directory they're located in different places but they all get installed somewhere like `/usr/local/lib/cmake//` The build directory is also different depending on the build type, i.e. `build/Release` or `build/Debug` – schrödinbug Jun 08 '23 at 16:29
  • so `` is the folder where they get installed in the package, so for me, my standard practice is to install them into `lib/cmake/`, that line for me becomes `self.cpp_info.builddirs.append(os.path.join("lib","cmake", self.name))` If you want to clarify that in your answer (i.e. where the path is relative to), I'll finally accept the answer. Hard-coding `lib` seems a little off since that's actually defined by `GNUInstallDirs` within CMake. – schrödinbug Jun 08 '23 at 20:21