Drop properties from legacy cmake generators

[czoido]

Changelog: Feature: Legacy cmake generators (cmake_find_package, cmake_find_package_multi) don't listen to new set_properties model anymore.
Changelog: Fix: Fix <PackageName>_FIND_COMPONENTS CMake generated variable to the correct value associated with the filename, not the package name.
Docs: conan-io/docs#2316

Related to: #10077 (comment)

#TAGS: slow

[memsharded]

was this a bug? How is this connected to not listening to properties?

[czoido]

Yes, I commented this here, as it's also happening for CMakeDeps, I have extended test_component_not_found_cmake to cover this.
The thing is that CMake generates a <PackageName>_FIND_COMPONENTS when COMPONENTS are specified in the find_package, but we are using pkg_name here that may not be the same as the <PackageName> CMake variable that is equivalent to our filename.

[czoido]

I was going the fix this in for CMakeDeps in the PR for CMakeDeps and absolute targets but I can fix all of them in another PR as well...

[memsharded]

Please, lets make sure to validate this, the develop branch against ConanCenter recipes (with .names recovered) before releasing 1.43

[planetmarshall]

Does this not contradict the migration docs? If I read that correctly,

self.cpp_info.set_property("cmake_file_name", "my_package")

should be synonymous with

self.cpp_info.filenames[“cmake_find_package"] = "my_package"

But as of this PR that appears to be no longer the case, and I need to set both if I want the recipe to be compatible with downstream recipes using the cmake_find_package generator.

[memsharded]

Hi @planetmarshall

Yes, maybe the docs are not clear enough: they are completely different and exclusive mechanisms. If you want to keep your recipes with cmake_find_package generator, yes, you need to maintain the self.cpp_info.filenames["cmake_find_package"] way. The new set_property("cmake_file_name") will only be used by the new generators like CMakeDeps. In summary:

• cpp_info.filenames exclusively for legacy generators like cmake_find_package
• cpp_info.set_property("cmake_file_name") exclusively for new generators like CMakeDeps
• Recipes that want to support both generators simultaneously, need to define both.

Lets add a note for that clarifying in the docs.