Is the wrapper compatible with packages that provide their own cmake config files?

[ottmar-zittlau]

Hi,

I'd like to use the wrapper with a package that provides its own cmake-files,
i.e. uses the settings:

    def package_info(self):
        self.cpp_info.set_property("cmake_find_mode", "none")
        self.cpp_info.builddirs.append(os.path.join("lib", "cmake", "package"))

However, it doesn't seem to work. Should it work? Can I somehow debug it?
Did I specify the builddirs correctly? The path should be valid relative to the package root.

Thanks and best regards
oz

[ottmar-zittlau]

Ah, if I understand https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.html correctly, this only works with the toolchain-generator.

[jcar87]

Hi @ottmar-zittlau - the idea is that it should work yes, if it doesn't then that's something we need to fix!

[ottmar-zittlau]

Thanks for your feedback - that would be great.

I found in the documentation (https://docs.conan.io/2/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.html) the following quote:

The consumer conanfile.py doesn’t need to use CMakeDeps at all, only generators = "CMakeToolchain". Note that the CMakeToolchain generator is still necessary, because the mypkgConfig.cmake needs to be found inside the Conan cache. The CMakeToolchain generated conan_toolchain.cmake file contains these paths defined.

I have activated the toolchain-generator and in the generated conan_toolchain.cmake I find the lines

# Definition of CMAKE_PREFIX_PATH, CMAKE_XXXXX_PATH
# The explicitly defined "builddirs" of "host" context dependencies must be in PREFIX_PATH
list(PREPEND CMAKE_PREFIX_PATH "/home/user/.conan2/p/b/pack1e804a97d5fc0/p/lib/cmake/package")

However, I don't see anything like this when only using the CMakeDeps generator. I think it would be necessary that CMakeDeps also generates a file containing this information.

I looked around the conan code a bit and found this PR: conan-io/conan#16964
It introduces a new cmakedeps generator, which should be able to generate a file called conan_cmakedeps_paths.cmake containing the required information (https://github.com/conan-io/conan/blob/9a7f9e2a5628a8646ccc7aadbcf4bb924bd4b959/conan/tools/cmake/cmakedeps2/cmakedeps.py#L223).

The pull request description states, that the new generator can be activated by tools.cmake.cmakedeps:new conf with value will_break_next. This seems to be a setting in the profile (conan-io/conan#16908).

If I run cmake install on the command line with this setting it works, but I didn't manage to get it working from within cmake. I use

set(CONAN_INSTALL_ARGS "--build=missing --conf tools.cmake.cmakedeps:new=will_break_next")
set(CMAKE_PROJECT_TOP_LEVEL_INCLUDES conan_provider.cmake)

project(test LANGUAGES CXX)

find_package(package REQUIRED)

I think it would be necessary to use the new CMakeDeps generator in the provider script and then use the generated paths file to find packages.

Do you have an idea when such an integration could be done? I would like to avoid writing all the cpp_info-overhead for our packages and this would simplify this a lot, because we already have all the cmake-configuration-files.

I could also try my hand at it, but I don't fully understand the consequences of including the generated paths file in the conan provider. It would also be interesting to understand, what the status of the new cmakedeps-generator is? Is this something that will replace the old one anytime soon?

Best regards
oz