[question] Consistency in package and generator names

[stefan-floeren]

After the discussion in conan-io/conan#6269 (comment), most packages got normalized to use the format discussed in this comment (#690 and related).

If I understand the intention correctly, in CMake the package should always be added with CONAN_PKG::{name} (for example openssl) and conan will then expand the correct Find*-macro using self.cpp_info.names["cmake_find_package"] or self.cpp_info.names["cmake_find_package_multi"] (in this case OpenSSL).

Some recipes now use an additonal self.cpp_info.names['cmake'] (a cursory search found libcurl and backward-cpp).

This leads to strange behavior:

• the cmake generator expects CONAN_PKG::CURL and will fail with CONAN_PKG::libcurl
• the cmake_multi works the opposite way, working with CONAN_PKG::libcurl and failing with uppercase CURL

In terms of consistency, I tend to say that the behavior of cmake_multi is the correct one, but either way, both CMake-variants should at least behave the same way.

I'm not sure if there are any side effects in removing the offending lines.

I didn't check if other generators have a similar behavior for different packages.

It might be a good idea to double-check all occurrences of superfluous or missing cpp_info.names, (tcl, for example is missing the multi entry). Is there a specific reason to split cmake and cmake_multi in this case (maybe a question to move to the main conan repo)?

[Morwenn]

There's actually an additional hook proposed for conan-center (conan-io/hooks#142) which:

• Warns when cpp_info.name is used
• Warns when cpp_info.names['cmake'] is used

That said it doesn't warn about cpp_info.names['cmake_multi'], which it should probably do if the goal is to remain consistent with the cmake equivalent.

I do agree that cpp_info.names should not have a different different from the package name for cmake and cmake_multi: it doesn't really add much value and kind of breaks CMake.patch_config_paths from the build helper (it's not a problem for Conan Center in isolation, but I have custom recipes that still export their own CMake config files and rely on this function to work).

[danimtb]

Indeed I think this is a bug in those recipes that should be fixed