Repository: conan-io/conan-center-index

Issue:
[question] Consistency in package and generator names
After the discussion in https://github.com/conan-io/conan/issues/6269#issuecomment-570182130, most packages got normalized to use the format discussed in this comment (https://github.com/conan-io/conan-center-index/pull/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](https://github.com/conan-io/conan-center-index/blob/ee20546/recipes/libcurl/all/conanfile.py#L374) and [backward-cpp](https://github.com/conan-io/conan-center-index/blob/ee20546/recipes/backward-cpp/all/conanfile.py#L114)).

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](https://github.com/conan-io/conan-center-index/blob/ee20546/recipes/tcl/8.6.10/conanfile.py#L198), 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)?


Discussion:
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).
Indeed I think this is a bug in those recipes that should be fixed

Resolving patch:
diff --git a/recipes/libcurl/all/conanfile.py b/recipes/libcurl/all/conanfile.py
--- a/recipes/libcurl/all/conanfile.py
+++ b/recipes/libcurl/all/conanfile.py
@@ -371,7 +371,6 @@ def package(self):
             os.remove(os.path.join(self.package_folder, 'lib', 'libcurl.la'))
 
     def package_info(self):
-        self.cpp_info.names['cmake'] = 'CURL'
         self.cpp_info.names['cmake_find_package'] = 'CURL'
         self.cpp_info.names['cmake_find_package_multi'] = 'CURL'
 


Test patch: