[question] Consuming an existing PackageConfig.cmake with the newer generators.
See original GitHub issueFor our modular developments, we maintain a Conan based workflow. It allows us to satisfy both external dependencies (usually fetched from Conan center) and internals dependencies that we host ourselves. All our repositories rely on CMake to generate build files for the different environments.
An important aspect of our approach is that Conan is not a requirement to build the projects (even though it helps greatly ; ).
This means that a “CMake-only” workflow is also possible, which implies that the CMake scripts produce self-sufficient PackageConfig.cmake
to be consumed by other CMake projects further downstream.
Older generators
With older generators, we relied on CMakePaths
to populate the required CMake variables so the CMake configuration phase would find the different PackageConfig.cmake
that our internal repositories are producing, and all was working as expected.
Newer generators
We are not aware of a way to consume the PackageConfig.cmake
generated by CMake. All generators seems to generate such package config directly.
- Is there a way to directly consume an existing
PackageConfig.cmake
? - If not, would there be an interest to officially support it?
We understand some of the benefits of having the newer generators fully generate the config file via the content of package_info()
, in particular with regard to the ability to become “generator agnostic” (i.e. using a generator that does not output for CMake).
In the meantime, there are also several advantages to allowing to directly consume an existing config CMake.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (3 by maintainers)
Hi @Adnn
yes, the new
CMakeToolchain
has functionality to add to the CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH the necessary paths inside your packages to find your packagedPackageConfig.cmake
. It is basically the same that thecmake_paths
was doing, but integrated in theCMakeToolchain
. Did you try it?It is recommended that recipes declare them in
cpp_info.builddirs
even if in the past it was not mandatory and putting them in the package root was enough, but it will help moving forward to 2.0 too.We have been working with the approach described above with single configuration generators with success.
Yet, we are currently hitting a major obstacle by trying to integrate multi-configuration generators (such as Visual Studio), maybe you could have a suggestion @memsharded
We have a recipe using the default
cmake_layout()
and the following generators:When we
require
a 3rd party library,CMakeDeps
generate the CMake package config and target files for all installed configurations inbuild/generators
. This correctly redirects to the corresponding library binary when changing the configuration (Release/Debug) from the IDE.When it comes to our internal package, as the discussion above indicates, we both explicitly disable
CMakeDeps
config file generation, and provide the path to the installed custom CMake configs with:Yet, this approach does not work out of the box with the multi-configuration IDE. When we
conan install
for the different configurations we would like to support from the IDE, each configuration results in a separate Conan package (as expected), and each configuration places its own CMake config in its folder, instead of having all configurations available in a common folder.Do you have any suggestion to make this approach work? Is there a way to instruct
CMakeDeps
to somehow “copy” or “link to” the different CMake package configurations?