Conan claims to work well with CMake and find_package, but if you spend any time trying to get well known dependencies such as Zlib or SDL2 to work with it you'll quickly find calling find_package when Conan packages are available produces different results than calling it when those packages are installed through older or more “standard” means.

Quick recap: using CMake's find_package command causes CMake to load information on an external package and pulls targets (think: namespaced global variables) into scope. Unfortunately the naming schemes that Conan gives these targets wind up being different than the ones CMake chooses.

For example, here's how find_package might look for the Boost libraries and Zlib if both dependencies were installed locally, using a mechanism such as apt-get install for Debian linux:

find_package(boost)
find_package(ZLIB)
...
target_link_libraries(my_lib PUBLIC boost::headers ZLIB::ZLIB)

There is no intuitive way to know what targets find_package pulls in, as they differ for every package. However, CMake has built in support over a hundred packages and you can find details of how they behave by looking at the docs.

Unfortunately Conan - which offers access to hundreds of packages CMake doesn't have native support for - does not play nice with the built in naming schemes of Cmake. For example, if you're using the Conan packages for Zlib, you have to do this:

find_package(zlib)
target_link_libraries(my_lib PUBLIC zlib::zlib)

It should be possible, in theory, for Conan to support the naming schemes CMake gives for every package it has built in support for. The mainainers of each Conan dependency (such as zlib) would just need to create CMake configuration files, which would get installed with the rest of the package's data. In fact, some present this as the best practice to follow if you're creating your own Conan packages (I happen to agree).

However, the thought leaders behind the biggest Conan packaging repositories explicitly choose not to do this. They even go so far as to delete the CMake configuration files created by the authors of the software they are packaging for use by Conan.

I'm positive that the people working full time on Conan packages have probably thought over their reasoning here more than I possibly could have, but still: this really, really sucks. It makes a lie out of the promise that you can use Conan while keeping your CMake scripts exactly the same as they would have been, and hurts people's ability to create and distribute CMake packages that will also work with tools such as cget and vcpkg.