Conan: [question] What if a FindModule.cmake file doesn't match package name?

Created on 17 May 2020  路  9Comments  路  Source: conan-io/conan

Hi,

I'm writing a package manager-agnostic project with optional Conan support. I want users to be able to use cmake commands if, say, they use apt or yum to install their dependencies. But I also want users to use Conan to pull those packages in 'nicely' if they choose.

I've hit a problem with Google Test because the Conan package is called _gtest_ but the CMake module is called _GTest_.

I'm using cmake_find_package which generates _my-build-folder/Findgtest.cmake_ and it works just great. But when I don't use Conan, users will probably want to use the CMake-provided file, e.g. _/usr/share/cmake-3.16/Modules/FindGTest.cmake_.

This means that in my Conan-agnostic CMake script, find_package(gtest) doesn't work for system-installed package and find_package(GTest) doesn't work for Conan-installed package.

How do I resolve this difference?
Thanks, John

P.S. I tried cmake_find_package_multi but hit different issues with MSVC and I think you'd still get a mismatch between _Configgtest.cmake_ and _ConfigGTest.cmake_.

question

All 9 comments

Hi @johnmcfarlane

In theory, the self.cpp_info.generators["generator"].name should normalize the Conan package name and use the same one as the mainstream one, this is the current code:

        self.cpp_info.names["cmake_find_package"] = "GTest"
        self.cpp_info.names["cmake_find_package_multi"] = "GTest"

I thought that the filename didn't actually matter, and cmake was case-insensitive in this regard, so the above was used only for the targets, but not for the filename. Is it the case that the Configxxxxx.cmake filename matters? cc / @danimtb @uilianries @SSE4 In that case we might want to use it for the filename too?

Hi @memsharded,

Thanks. Yes, find_package tries a number of different filenames but I think they are case sensitive. You can test this quickly by mutating the case of an argument to a REQUIRED package and seeing how it breaks.

However, I'm not impeded by this currently. I fund that cmake_paths is a satisfactory alternatively generator for me when using instructions here.

Hi!

The name assigned in the self.cpp_info.names["cmake_find_package"] modifies also the FindXXXX.cmake name.

Those two lines provided above by memsharded are exactly what the community is doing for the GTest recipe in Conan Center:

https://github.com/conan-io/conan-center-index/blob/83a7e1a6e7bcb46c933447618089c05e2ac9d6b0/recipes/gtest/all/conanfile.py#L92

Had a look, and can confirm:

  • the self.cpp_info.names["cmake_find_package"] correctly modifies the cmake name, both for the filename, the find_package and the target, to match the upstream (cmake) behavior
  • If this is not the case, then it is a recipe issue, should be reported to conan-center-index or to the package maintainer, so they provide the correct self.cpp_info.names["cmake_find_package"] to have transparent naming.

Thanks for the feedback, I think this can be closed now.

@memsharded thanks for taking a look. However, I'm still a little confused. With recipe

from conans import ConanFile

class Issue7039Conan(ConanFile):
    generators = "cmake_find_package"
    requires = "gtest/1.8.1@bincrafters/stable"

the command

conan install . --build gtest

writes the file, _Findgtest.cmake_, with Conan 1.25.2. It seems like we agree that this is the wrong name and that it's not a problem with the package.

Again, I'm not blocked and was merely curious. But what would I do to work around this problem in future?

Hi @johnmcfarlane

You are using the old recipe, not the updated one from ConanCenter. Use:

from conans import ConanFile

class Issue7039Conan(ConanFile):
    generators = "cmake_find_package"
    requires = "gtest/1.8.1"  # Without the "@bincrafters/stable

Updated recipes, created with the automatic build service of conan-center-index do not use "@user/channel" part.

This new recipe will produce the right filenames and targets with GTest.

As a side comment, you might find really useful the markdown generator:

conan install gtest/1.8.1@ -g markdown

It generates a gtest.md file, it is a plain text file that you can open with any IDE and (if you have a plugin to render markdown) it will offer you a nice document with all relevant data:

_Users_jgsogo_dev_conan_conan_gtest md

Sorry to dredge up such an old thread but I cannot get this package to work with the _cmake_find_package_ (and without conan_basic_setup()). CMake's GTest module has two targets: GTest::GTest and GTest::Main but there's no sign of GTest::Main in the FindGTest.cmake being produced by _cmake_find_package_. It provides GTest::gtest_main but the CMake module does not provide this, so there is no overlap I can find between CMake's and Conan's module.

Hi @johnmcfarlane

Yes, you are right. This is a known, reported issue in https://github.com/conan-io/conan-center-index/issues/3222, it is there in the queue to be fixed:

The recipe in ConanCenter uses the name of the more modern, recommended Config.cmake approach, which is gtest_main, but it seems the target when using the find.cmake older CMake approach is different, and the recipe hasn't yet accounted for this. CMake tends to be often inconsistent in find scripts, and this is a lot of work for the ConanCenter maintainers. Hopefully it can be fixed soon, if not, moving to the new Config modules instead of Find ones, might help.

Was this page helpful?
0 / 5 - 0 ratings