Add way to specify xxx for Findxxx.cmake with cmake_find_package generator

[bmanga]

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Conan 1.18

Currently the cmake_find_package produces Findxxx.cmake where the package name matches the name of the conan package. This is a problem for libraries like Boost and Eigen, which are packaged with lowercase names but most CMakeLists use find_package(Boost/Eigen). In these cases, CMake does not consider conan's generated files.

Would it be possible to add another optional variable to ConanFile which would be a list of names to control this, eg:

class EigenConan(ConanFile):
    ...
    cmake_find_package_names = ["Eigen", "eigen"] # generates both FindEigen.cmake and Findeigen.cmake

Alternatively (or additionally) could a way to specify the name be added to the conanfile of the project?

[bmanga]

On a second thought, given that most of the libraries with this problem do provide their own cmake files, maybe there should be a variable to tell conan that the generated FindXXX.cmake should just be wrappers to those.

[lasote]

Hi!
We have this PR https://github.com/conan-io/conan/pull/5598/files assigned for the next 1.19 release.
The package can declare a self.cpp_info.name field that will be used by the generators to create the xxxConfig.cmake or FindXXX.cmake files with that name instead of the name of the package.

On a second thought, given that most of the libraries with this problem do provide their own cmake files, maybe there should be a variable to tell conan that the generated FindXXX.cmake should just be wrappers to those.

We don't recommend the packages to package these Find scripts. The package should be able to be consumed with any build system and not only with CMake. The information given in the self.cpp_info should be complete enough so Conan, with the generators, can generate the right files.
But anyway if you are in a company or controlled environment and all the packages will use CMake it is ok to package the scripts if you take care of avoiding absolute paths inside and so on.

[madebr]

@lasote #5598 is very useful but imho conan needs a more powerful solution.
e.g. CmakeFindOpenSSL defines a lot of variables and targets.
Also, the casings of the variables and the name of the module differ.

In package_info(), it'ld be nice if it would be possible to do the following:

def package_info(self):
    self.cpp_info.name = "OpenSSL"
    crypto_target = Target(libs=['libcrypto'], defines=['OPENSSL_CRYPTO'], include_dirs=self.cpp_info.includedirs, deps=[self.deps_cpp_info["imaginary"].targets["libsomething"]])
    ssl_target = Target(libs=['libssl'], includes=self.cpp_info.includedirs, deps=[crypto_target])
    self.cpp_info.targets.Crypto = crypto_target
    self.cpp_info.targets.SSL = ssl_target
    self.cpp_info.cmake.variables["OPENSSL_LIBRARIES"] = tools.collect_libs(self)

conan should then have sufficient information to create the targets OpenSSL::crypto and OpenSSL:SSL.
Also, it will generate the variable OPENSSL_LIBRARIES in addition to the variable OpenSSL_LIBRARIES, that is automatically added by the cmake_find_package generator.

[lasote]

That would be very complex, we are not going to play the game of emulating the CMake find package scripts like https://cmake.org/cmake/help/latest/module/FindOpenSSL.html
We think a "find" script is the responsibility of the package manager and we assume that the consumers will need to adapt the cmake scripts in some cases, because the target and vars generated by Conan won't be the same as the cmake module, the same the cmake module files changes among the cmake versions.

[madebr]

@lasote Indeed, this could get complex.

I just discovered the self.cpp_info.build_modules feature.
Then, the openssl recipe could package a cmake script that creates the OpenSSL::Crypto and OpenSSL::SSL target.

The difficulty with this approach is the following:
please have a look at package_info of openssl as a reference

OpenSSL::Crypto would only need to link to the libcrypto/crypto libraries (and other windows libraries) (libssl should not be added to the target)
OpenSSL::SSL would need to need to link to libssl and OpenSSL::Crypto.

My problem lies in the way how to convey these lists of libs from package_info to the cmake script without copying code.
I like to avoid adding code to avoid using regexes or list manipulation to remove the libssl target from the list of libs.

The cmake_find_package generator will find the file paths of the openssl libraries. It would be nice to also use these paths for these custom cmake targets.

[madebr]

The original question of this issue has been solved.
I have opened #6587 to address my question.

[jgsogo]

Thanks. Closing this one then.