conan: [bug] conan 1.42.0: CMakeDeps does not inherit anymore from cmake_find_package_multi names

Ok. Therefore I believe that:

• CMakeDeps shouldn’t be promoted by conan team (in tutorials, and Slack/reddit etc) until CCI recipes properly support it. CMakeToolchain + cmake_find_package* is the way to go currently.
• Transition to set_property() in CCI (and therefore proper support of CMakeDeps) should begin when set_property() is stable enough. CMakeDeps shouldn’t be recommended for consumers until the end of this transition.

I guess what @SpaceIm means is that if you lowercase the config file

touch xyz-config.cmake

then all of

cmake_minimum_required(VERSION 2.8)
project(xxx)
find_package(XYZ CONFIG REQUIRED)
find_package(Xyz CONFIG REQUIRED)
find_package(xyz CONFIG REQUIRED)

should now work on all platforms.

I understand this is unfortunate, but in our defense, most of this came from a new requisite, that didn’t exist before when CMakeDeps was starting to be promoted, and it is the need to define new ways of defining specific target names (with custom namespaces, etc). We couldn’t foresee that, and the path forward in the migration is now more painful than expected. I really apologize for it. But also this is the case where the experimental qualifier kicks in. The fact that we have been doing a huge effort in not breaking other features labeled as experimental doesn’t mean that at some point we would need to break one of them. Otherwise we would always be stuck in a very bad situation: nobody ever uses and tests new features, so they are never improved, so they keep experimental forever.

Said that, I totally understand the pain, so lets try to alleviate it as fast as possible:

• Lets stop promoting CMakeDeps until the properties are stabilized
• Lets stabilize the final properties in 1.43
• Lets try to put extra resources as soon as 1.43 is available in conan-center-index to update recipes to use those final properties.

Thanks very much for the feedback.

There is way more Conan usage out there not using ConanCenter than using it. The estimation is around 70-80% of users do not depend on ConanCenter, but maintain their own recipes (forks or from scratch) for third party packages

Let’s take Boost as an example. I don’t believe there are 70% serious C++ software developers not ever using it or recreated its recipe from scratch. If they’re so unlucky to adopt CMakeDeps in their projects (like me) - they’re toast now. Yes, I forked Boost recipe and fixed it internally but it’s big pain, Boost is not the only one. Your argument that CMakeDeps is experimental does not quite convince me: it’s you who recommended it for new projects as other CMake generators will disappear in the near future: https://github.com/conan-io/conan/issues/9108#issuecomment-861534321 Yes, it’s experimental but there are many features that are still experimental like python requires. components or lock files but without them one just can’t use Conan nowadays. And a new Conan release that just makes such a feature completely unusable in many existing recipes without deprecation notice is IMHO unacceptable.

I think this can be closed, it is expected that CMakeDeps is not using those names anymore, and there are other initiatives (updating recipes in ConanCenter with newer properties) to fix this. But please tell if I am missing something. Thanks.