[feature] CMakeToolchain: remove CMAKE_FIND_PACKAGE_PREFER_CONFIG ON

• I’ve read the CONTRIBUTING guide.

CMAKE_FIND_PACKAGE_PREFER_CONFIG ON in CMakeToolchain originally addressed this problem:

• CMakeDeps is supposed to be able to work in conjunction with CMakeDeps (cmake_find_package & cmake_find_package_multi removed in conan v2).
• CMakeDeps was supposed to generate only CMake config files.
• by default CMake looks first for Find files, then config files in a call like find_package(foo) (without CONFIG or NO_MODULE).
• it would have been an issue for consumers/recipes depending on recipes packaging libraries listed in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules, since those modules would have take precedence over config files generated by CMakeDeps. Indeed, no one in C++ ecosystem has ever written in its CMakeLists find_package(ZLIB REQUIRED CONFIG).

But now:

• CMakeDeps has learned generation of Find module files when a recipe set cmake_find_mode property to both in package_info().
• all CCI recipes listed in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules have been updated so that CMakeDeps will always generate both Find & config files.

There is no more reason to keep CMAKE_FIND_PACKAGE_PREFER_CONFIG ON. it may have undesirable side effects. For example an agnostic CMakeLists looking for one of the files in https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html#find-modules, may ends up with the config file which have different target names than the Find file (there are few cases like freetype and expat, which have built-in CMake modules files in CMake installation, and also provide config files. Target names are different but not the Find & config file names).

[SpaceIm]

Just follow upstream convention? I don’t understand all these questions. It’s even explicitly described in https://cmake.org/cmake/help/latest/module/FindVTK.html

FindVTK.cmake is the module file VTKConfig.cmake is the config file

So a vtk recipe should follow these names in package_info(), it’s the only criteria.

[memsharded]

conan won’t force anything. It’s the opposite with my proposal, conan would allow you to write a good agnostic CMakeLists. If they want to use expat-config.cmake, they must write find_package(expat REQUIRED CONFIG), because it’s what would work outside of conan.

Ok, yes, now I see what you mean, thanks for explaining!