Get ``CMakeConfigDeps`` out of incubating

[memsharded]

The new CMakeConfigDeps is "incubating".

We need feedback to stabilize it. If you want it out of "incubating" stage, please provide your feedback, just a few lines with:

• Report how you have tried it, and report success
• Report a bit about your project, size of project, number of dependencies, if mostly against ConanCenter dependencies or your own dependencies, etc.
• Report the "features" or improvements of CMakeConfigDeps that you value over and are willing to use, compared with the CMakeDeps generator.

Please post a comment in this thread with those details. We will get it out of incubating when we have enough evidence and feedback. Thanks very much!

[michaelmayer]

I can report success on using the CMakeConfigDeps as a drop in replacement for the CMakeDeps. Very few recipes might need some minor re-adjustments, like correcting cmake names.

Main goal with our recipes is that they work with the CMakeToolchain generator alone, using package-provided CMake config files. But for "editable mode" and for our colleagues working with VS or XCode, support for CMake multiconfig generator is needed.
Main problems with the old one are the generated proxy-targets (INTERFACE instead of IMPORTED), so that CMake's TARGET_RUNTIME_DLLS expression and the like don't work without additional effort.

We host all packages (even third-party) on our in-house Artifactory. All in all about 50 or so, including static and dynamic libraries, executables and also simple resource packages (like cmake modules, and json/xml/etc files).
Some of our packages also provide multiple components.

[Emiliskog]

We tried to use this for our build which uses an inhouse artifactory setup but mostly the conan-center-index recipes with minor modifications and found we got issues building QWT due to dependencies on xkeyboard-config via xkbcommon which exposes it but in the system we use (RHEL8/9) at least it doesn't provide libs to make a target but is still linked against due to the exposure in xkbcommon

[memsharded]

Hi @Emiliskog

Sorry, it is not fully clear if your comment is a "everything ok, working good", or it is an issue report. This thread is only for approval comments, positive feedback to get the CMakeConfigDeps out of incubating. If there is something that is not working, please better create a new ticket reporting it with details to reproduce. Many thanks.

[Emiliskog]

Hi @Emiliskog

Sorry, it is not fully clear if your comment is a "everything ok, working good", or it is an issue report. This thread is only for approval comments, positive feedback to get the CMakeConfigDeps out of incubating. If there is something that is not working, please better create a new ticket reporting it with details to reproduce. Many thanks.

yeah sorry got a bit confused, we had a bug we ran into which I have now reported https://github.com/conan-io/conan/issues/18597 otherwise from what we can see this should work so much better for our purposes as are working on an installation script in cmake which works better when the targets are properly set up with imported locations and the like than having to work backward from interface_link_libraries

[aagor]

I'm wondering how to test CMakeConfigDeps in a good way? Is there a config option to switch CMakeDeps to CMakeConfigDeps? If not, testing seems complicated expect for single packages.

[Emiliskog]

I'm wondering how to test CMakeConfigDeps in a good way? Is there a config option to switch CMakeDeps to CMakeConfigDeps? If not, testing seems complicated expect for single packages.

From the incubating page of the documentation adding -"c tools.cmake.cmakedeps:new=will_break_next" option on the command line should build with cmakeconfigdeps where cmakedeps has been chosen to use

[aagor]

From the incubating page of the documentation adding -"c tools.cmake.cmakedeps:new=will_break_next" option on the command line should build with cmakeconfigdeps where cmakedeps has been chosen to use

Ah yes, you're absolutely right. I was confused, as this config option is even needed when switching manually to CMakeConfigDeps inside the conanfile.py. But indeed, this config option is sufficient even with CMakeDeps inside conanfile.py.

[hpe-ykoehler]

@memsharded last time I tried with conan 2.11, I had an issue cross-compiling the conan-center-index recipes with the option, was this attempted since and what were your result?

[jcar87]

@memsharded last time I tried with conan 2.11, I had an issue cross-compiling the conan-center-index recipes with the option, was this attempted since and what were your result?

Hi @hpe-ykoehler - any recipe in particular that was failing to build? So that we can reproduce the error and diagnose and fix where necessary, thanks

[hpe-ykoehler]

I just try with conan 2.19 and hit an issue with libiconv where the iconv.h include statement in test_package worked but the next line #include "libcharset.h" didn'.t

I think I found a way around it but it seems like a bug. I added an explicite dependency on libiconv::_charset to the test_package/CMakeLists.txt (still awaiting test result to confirm) -- no that didn't work either...

This package use the ".libs" https://github.com/conan-io/conan-center-index/blob/master/recipes/libiconv/all/conanfile.py#L139 instead of hte .components

[memsharded]

Hi all,

Please recall the comments above:

• This thread is not for reporting failing issues with CMakeConfigDeps
• This thread is exclusively for reporting "Everything OK, everything is fine from our side, the CMakeConfigDeps can be moved out of incubating to General Availability in Conan"
• For any failing issue, the process is to create a new ticket for it, recommended to add CMakeConfigDeps in the title, and you can feel free to link this current ticket.
• Then, when that ticket is fixed and everything works well for your case, come back to this current ticket and comment to "Everything OK, get CMakeConfigDeps out of incubating"

[hpe-ykoehler]

@memsharded I think I was answering the question properly.

The CMakeConfigDeps cannot go out of incubating until successfully compilation of conan-center-index occurs, right?

As such, I was pointing out that as of today, conan-center-index fails to compile with this feature.

Now, is it ok to report a ticket to a conan-center-index packet about a feature which is in incubation?

[memsharded]

The CMakeConfigDeps cannot go out of incubating until successfully compilation of conan-center-index occurs, right?

Yes, it can. There might be issues in recipes in ConanCenter that needs to be updated for CMakeConfigDeps to work properly. As the generator in production is opt-in, there isn't an issue with that at all. As long as CMakeConfigDeps generates enough value for users that report in this thread that the generator is working for them even if they are not using ConanCenter recipes, then the generator can leave incubating. We are looking for value and relative stability, not completeness over ConanCenter recipes.

As such, I was pointing out that as of today, conan-center-index fails to compile with this feature.

Now, is it ok to report a ticket to a conan-center-index packet about a feature which is in incubation?

Better to report tickets in this repo, not in conan-center-index yet. We will triage them and check what to do and transfer to conan-center-index if necessary. However, it is much better if those cases can be reduced to minimal reproducible examples, not using libraries that sometimes take hours to build, and that makes it much harder to allocate the time to investigate them.

[Juliyo]

I'd like to share some positive feedback from a proof-of-concept project using the incubating CMakeConfigDeps generator and add my vote for its stabilization.

My main test case was centered around the common developer workflow of iterating on a library. With the standard CMakeDeps and CMakeToolchain (using cmake_find_mode="none"), I found that when I updated a dependency by running conan create ., any consumer project would fail to pick up the new version. CMake would hold onto the path of the old package, and the only way to get the update was to manually clean the CMake cache.

I can confirm that by switching my test project to CMakeConfigDeps, this problem was completely resolved. After updating the library with conan create . and re-running the consumer's build, CMake correctly detected the new package version from the Conan cache without any need for a manual cache clean.

Although I haven't tested CMakeConfigDeps in-depth on a large-scale production project yet, this initial result is very positive sign for improving the local development loop.

[Giulio-D-Delem]

I have some feedback for the CMakeConfigDeps generator and I can say, it works really well!

Brief description of my problem: I recently embedded conan package cairo/1.18.0 into a project I'm working on for the company I work for. The cairo package has one dependency: pixman. It came to my attention that building the project, consuming these packages didn't work, because the linker could not find any references to pixman related things. Apparently they aren't visible to the build context, or something like that. And I needed some ugly workaround in my conanfile.py to make it work.

So I posted about this and one recommended to use the new CMakeConfigDeps generator that is in development. What I can say is that it works out of the box, it solved my original problem and I don't need my workaround anymore. Also the rest of the project still works really well with this new generator.

Many thanks for this!

Some numbers on the project I work for:

• Project itself has 1M+ LOC
• The latest version has 20+ conan dependencies, about a third of those are packages of recipes we've written ourselves, the rest are conan-center packages/recipes