CMakeDeps/CMakeToolchain: Several improvements for open issues - #9455

So far I think this kind of flexibility will be needed if we want to support all the scenarios out there and adapt to the existing [nightmare] ecosystem. Probably we need a decision about the use-cases that we won't cover and how to workaround them: build-modules, patches to consumer sources, duplicated files for Meson,... that can help us to understand the full picture.

• CMakeToolchain: Added the build modules paths from the requirements to the CMAKE_PREFIX_PATH/CMAKE_MODULE_PATH. That would allow finding the config files packaged. THAT COULD BE OPT-IN MAYBE!

There can be different files that one consumer will always think it is the best one:

1. Conan generated files
2. Official files provided by the dependency (packaged in the Conan package)
3. Files provided by the consumer itself: some libraries provide their own scripts to find the dependencies and populate custom variables
4. Official CMake files (related: [package] opengl/system: CMake find module incompatible with standard FindOpenGL conan-center-index#2311)

Depending on how intrusive Conan wants to be, we will need more or fewer config parameters in the recipe to fit each scenario.

• CMakeDeps: Exclude generate the configs for a given dependency FROM THE CONSUMER, actually only available from the recipe of the dependency as a property. That would allow skipping the Conan-generated config file to use another one, like the packaged or whatever.

I don't like to have too many config parameters... but sometimes the same library mixes several of the previous approaches. You need some files provided by the library and for some others Conan generated ones are better. In this scenario you can remove selected ones in the recipe:

        for package in ("Fontconfig", "Freetype", "GDAL", "GIFLIB", "GTA", "Jasper", "OpenEXR"):
            # Prefer conan's find package scripts over osg's
            os.unlink(os.path.join(self._source_subfolder, "CMakeModules", "Find{}.cmake".format(package)))

• CMakeDeps: Added two new properties cmake_module_file_name and cmake_module_target_name (analog to cmake_file_name and cmake_target_name, but these new ones will activate the generation of FindXXX.cmake cmake scripts in order to use modules. This issue respond to this situation like this:

  • CMake installation has FindZLIB.cmake but the author (irrespective if we package or not the config files) have a zlib-config.cmake.
  • So Conan recipe needs to decide the name of the target...to make the consumers happy. ZLIBor zlib?
  • But not only that, a consumer might be doing find_package(zlib MODULE) so he won't be able to use config files.
  • That is happening is Conan center, and causing the recipe authors to use cmake, cmake_find_package or cmake_find_package_multi depending on how the CMakeLists consume the dependency, because cmake_find_package generate modules, cmake_find_package_multi generate config...

Life is hard 😢

This weekend I've been fighting with DART, I think it is a library with good build-system files (CMake) but with subtle details that make it a bit complicated: library-provided module files that use pkg_config to find dependencies, problems with multi-config generators, casing and names conflicts,... It would be very challenging to provide something that just is a drop-in replacement.

@SpaceIm @prince-chrismc @madebr WDYT? will it make your life easier/harder/same? any comments are welcomed.