Conan packages with canonical CMake name

[memsharded]

Hi Tim!

Reading https://border-town.com/blog.php?id=2020-06-13_09_32_55, I would like to clarify a bit:

• Conan has syntax to maintain the canonical CMake find_package name. It is the self.cpp_info.names attribute for the package_info() method.
• The packages in ConanCenter are since a few months ago being created from the https://github.com/conan-io/conan-center-index repository, instead of the older way of including them. The community is working very hard to move there old packages.
• Some packages, like the SDL one, are still not updated, and haven't started using the new syntax. Hopefully it will be contributed soon, and it will be easier to transparently consume it.
• A similar situation happens with "components". The feature was added in last release, it will take a bit until the existing packages are updated, but after that, usage of components should be transparent too.

[TimSimpson]

Thanks for reaching out. I'm glad addressing this is a priority for the major players in the Conan ecosystem.

I need to look into it some more but I'm guessing then Conan Center and BinCrafters would still prefer package writers to not package up the files created by CMake's built in commands such as install, write_basic_package_version_file etc but instead set the various package attributes you're describing in the conanfile? It's a drag the information would need to be duplicated (in the event people want to create CMake projects that could work with other package managers as well) but I guess that makes sense to me, especially if it helps with the long-term vision of allowing multiple build systems to interact.

Btw, I'm amazed you found that blog post, since I hadn't shown it to more than one person yet (are you somehow monitoring the whole internet at once ala Ozymandias? :smile: )

[memsharded]

Hi Tim,

Yes, this is an important priority. So far, Conan has had a very strong focus on the enterprise, and it is doing amazing there, when it is not a big issue to adapt things because the investment is already high. Recently, we are putting more resources in the wider community of open source consumers, and aiming for a better and more transparent integration with build systems, specially CMake:

• The self.cpp_info.names to match the canonical names
• The components feature
• The very new toolchain() (still super experimental), that can generate conan_toolchain.cmake files when necessary.

I need to look into it some more but I'm guessing then Conan Center and BinCrafters would still prefer package writers to not package up the files created by CMake's built in commands such as install, write_basic_package_version_file etc but instead set the various package attributes you're describing in the conanfile? It's a drag the information would need to be duplicated (in the event people want to create CMake projects that could work with other package managers as well) but I guess that makes sense to me, especially if it helps with the long-term vision of allowing multiple build systems to interact.

Yes, the long term vision is important, the idea is that it is totally possible to swap the build system of any package in a big dependency graph, without any problem and without affecting the other packages at all.

The problem that exists with the built-in or find_xxx.cmake scripts generated by CMake is that they have some known limitations, for example it is impossible to use them to consume multiple different configurations, for example Debug/Release/RelWithDebInfo, x64/x86, Static/shared, in a scalable way. Conan scales by having a different package for each configuration. This is super efficient, easy to model and scales without any issue, even for custom configurations. But find_package() basically does not work with that paradigm. Another major issue is that it sometimes handle transitivity very poorly, or completely incorrectly. Having a find_xxx.cmake of a Conan package to find the openssl from the system, instead of the user openssl in a Conan package, is not only annoying, but also an uncontrolled security risk. This is the reason we had to provide our own cmake_find_package generators, because they can model the transitivity without issues.

Regarding the macros, the strategy we are adopting in ConanCenter is to allow packaging those macros, in other .cmake files, and have those files automatically included. This can be declared in the self.cpp_info.build_modules.

So fortunately, the tools start to be there, now it is a matter of time that the community adopts them, and contribute updates to the ConanCenter packages. At the speed they are working, I think in a few months the situation will be very different, so far ConanCenter has processed +1200 pull requests since January, adding almost 400 new recipes to it.

Btw, I'm amazed you found that blog post, since I hadn't shown it to more than one person yet (are you somehow monitoring the whole internet at once ala Ozymandias?

Nop, we are not monitoring the internet 😅 We saw it on twitter: https://twitter.com/crascit/status/1272301071709302784?s=20

Thanks for the feedback!

[TimSimpson]

@memsharded That sounds wonderful. I went ahead and updated that post with a link to this conversation to make it clear that addressing this was a priority in the Conan community.

Honestly I had the impression that not using canonical CMake names was viewed as an acceptable loss from Conan's perspective and thus wouldn't be fixed. Partially this came from Reddit threads and less than official sources where people had raised the complaint and were dismissed by others saying it didn't matter. But I mainly it was because the CMake package config files were explicitly not allowed in Conan Center, there are recommendations against using find_package in BinCrafters and I didn't know alternate mechanisms existed to replicate what the CMake package config files were doing in Conan.

think in a few months the situation will be very different

I hope this is right. Given how quickly things move it seems like it could happen.

[memsharded]

@memsharded That sounds wonderful. I went ahead and updated that post with a link to this conversation to make it clear that addressing this was a priority in the Conan community.

Good, thanks!

Partially this came from Reddit threads and less than official sources where people had raised the complaint and were dismissed by others saying it didn't matter. But I mainly it was because the CMake package config files were explicitly not allowed in Conan Center, there are recommendations against using find_package in BinCrafters and I didn't know alternate mechanisms existed to replicate what the CMake package config files were doing in Conan.

To be fair, it is also true that in Conan we move fast and react to community inputs when possible, we release every month with new features and improvements, always based on users feedback. As commented above, Conan has always excelled in the enterprise, and only relatively recently we went back to trying to achieve a more transparent integration with the build systems. Many of the information out there in internet forums can be outdated.

So my recommendation for readers would be:

• If you feel something weird, or something you don't like or understand about Conan, the best is always refer to the official docs in https://docs.conan.io/
• If still don't find a reasonable answer, file an issue in https://github.com/conan-io/conan. We might give hints towards possible solutions, or if it is a feature, we might be able or not to address it quickly, but the cumulative feedback effect is what drives Conan in the long term, and if the community supports it, it will get higher priority. So still that feedback is gold for us, even if it cannot be fixed immediately.

[TimSimpson]

I've read the Conan docs many times, and try to keep up with the blog, but I totally missed the updates from April (in my defense, it's not like it was titled "Conan embraces support for generating correct CMake targets...).

One thing I'm curious about: who is the audience for the cmake_paths generator? Please correct me if I'm wrong, but it seems like using it can only be done if every single Conan package that is ever consumed has also exported CMake package config files and is built using the cmake_paths generator. Since it can end up leading to confusing situations are there any plans to deprecate it, or even give warnings if people try to export the CMake package config files as part of Conan packages?

[memsharded]

in my defense, it's not like it was titled "Conan embraces support for generating correct CMake targets...

Fair enough, the truth is that there are so many efforts ongoing simultaneously, that sometimes there are things that are not that highlighted from the rest in the titles.

Regarding the cmake_paths generator, it was born in one of the first attempts to use the packages find.cmake scripts, before we realized and learned the above described problems about transitivity and multi-configurations.

Yes, there are plans to deprecate it, as a generator, and most likely it will be integrated directly in the toolchain() feature. But still not fully sure, and as there are users that are using it (despite the limitations, if you know what you are doing, be careful and assume some controlled flows, it can be useful), we are not showing yet any warning or recommend to migrate to a different approach. We will do it when the toolchain matures.