question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[question] Consuming an existing PackageConfig.cmake with the newer generators.

See original GitHub issue

For 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:open
  • Created a year ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
memshardedcommented, May 25, 2022

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 packaged PackageConfig.cmake. It is basically the same that the cmake_paths was doing, but integrated in the CMakeToolchain. 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.

0reactions
Adnncommented, Aug 11, 2022

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:

generators = "CMakeDeps", "CMakeToolchain"

When we require a 3rd party library, CMakeDeps generate the CMake package config and target files for all installed configurations in build/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:

def package_info(self):
    # Disable the config package that would otherwise be generated by CMakeDeps
    self.cpp_info.set_property("cmake_find_mode", "none")

    # Find CMake-generated package config when consuming the (installed) conan package
    self.cpp_info.builddirs = [path.join("lib", "cmake")]

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?

Read more comments on GitHub >

github_iconTop Results From Across the Web

CMake 3.25.1 Documentation
Run cmake --help to see a list of generators available locally. ... New in version 3.25: See the cmake_language() command for a way...
Read more >
install: add EXPORT mode to generate pkg-config files (#22621)
We may be able to generate pkg-config files for CMake packages by extending install(EXPORT) with a mode to generate .pc files.
Read more >
CMake is not making makefile - Stack Overflow
cmake /? and you will see the list of the available generators. At the moment you generate for Visual Studio not not make...
Read more >
Changelog — conan 1.56.0 documentation
Conan 1.56 shouldn't break any existing 1.0 recipe or command line invocation. ... #11805; Bugfix: Update cmake_layout build and generators folders to honor ......
Read more >
CMake Command-Line Reference - manpages.ubuntu!
Run cmake --help to see a list of generators available locally. ... When using one of the Command-Line Build Tool Generators CMake expects...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found