Closed OliverHaag closed 1 week ago
Sure, CCI recipes are designed for cmake_find_package
, cmake_find_package_multi
and pkg_config
generators, not cmake_paths
generator.
See https://github.com/conan-io/conan-center-index/blob/master/docs/faqs.md#why-are-cmake-findconfig-files-and-pkg-config-files-not-packaged
Thanks for the quick response. I don't see a drawback in just leaving the find-scripts there and not forcefully breaking conan_paths. The linked answer doesn't really describe that decision, since there shouldn't be any collision between the packages own cmake-config and the CONAN_PKG:: targets. CMake just won't care about that files unless you issue find_package so I don't see any problems for the cmake_find_package* generators here. Mind explaining the decision further?
cmake_find_package
generator and CONAN_PKG::recipe
targets are completely different things.
cmake_find_package
emulates find modules files, and cmake_find_package_multi
emulates find config files. If you keep config files in a recipe, they will conflict with those generators.
Use cmake_find_package
or cmake_find_package_multi
, it's the way to go (+ generate()
eventually) for transparent integration of CCI recipes in CMake projects.
Sorry mixed up cmake_find_package and cmake generators there. But CMake wont search in the package folder anyway when using cmake_find_package so it will definitely not use any cmake-files included in the package and can't have any collision or am I wrong?
It depends.
cmake_find_package
and cmake_find_package_multi
don't append anything in CMAKE_PREFIX_PATH
and CMAKE_MODULE_PATH
, they just generate .cmake files where conan install
was executed.
On the other hand, nothing prevents someone to use more generators, like cmake
generator (then call conan_basic_setup()
), or to use a toolchain file generared by generate()
, which will append all package folders in CMAKE_PREFIX_PATH
and CMAKE_MODULE_PATH
, and if there are config files in these folders they will conflict with cmake_find_package
and cmake_find_package_multi
module/config files (they might take precedence over other module/config files depending on order of paths in CMAKE_PREFIX_PATH
and CMAKE_MODULE_PATH
).
Okay thanks, I see the problem in some scenarios. I tried out cmake_find_package now and it seems to not cause any problems with the find_package calls (and even avoids writing some Find-scripts for libs lacking those). One thing before closing this issue: Could the docs indicate that cmake_find_package should be preferred over cmake_paths and that cmake_paths will not work with CCI (referencing the answer your linked)? Should I open a separate issue for conan itself for this?
@OliverHaag please, open an issue about that in the documentation repo to add a note about the lack of support of conan center packages for that generator. Thank you
I just found this topic and I think it is closely related to my problem mentioned here: https://github.com/conan-io/conan-center-index/issues/4712
I need to use cmake_find_package_multi
, because another project that depends on ITK uses find_package(ITK NO_MODULE REQUIRED)
(so I need to generate an ITKConfig.cmake
-file).
However, the depending project also uses include(${ITK_USE_FILE})
, which is not defined. There is no UseITK.cmake
-file for this variable and thus building the project fails.
One solution would be to use the cmake
-generator instead of the cmake_find_package_multi
. This allows to rely on the original ITK config files.
However, this approach does not work with the conan-center ITK recipe, because the cmake
-directory was removed (because of tools.rmdir(os.path.join(self.package_folder, "lib", "cmake"))
.
I created my own ITK recipe that does not have this line (so the ITK config-files and UseITK.cmake
are available in the Conan-created package) and everything works as expected.
Maybe you can comment in the linked issue, what the recommended way to solve this problem would be.
The problem is more or less connected, but still different.
UseITK.cmake
could be kept and added to self.cpp_info.build_modules
in package_info()
(you can open a PR for that if you want). Indeed CCI doesn't forbid to keep CMake module files, only find/config CMake files.
The problem is more or less connected, but still different.
UseITK.cmake
could be kept and added toself.cpp_info.build_modules
inpackage_info()
(you can open a PR for that if you want). Indeed CCI doesn't forbid to keep CMake module files, only find/config CMake files.
I wouldn't know exactly what to do so although I want to open a PR I don't know what to change inside the recipe. The documentation is not clear for me at that point.
The generator cmake_paths
is no longer supported. Please, read how to integrate your project using new CMake generators in Conan 2.x: https://docs.conan.io/2/integrations/cmake.html
Package and Environment Details
Steps to reproduce
Pull boost/1.75.0 via a conanfile.py and use the conan_paths generator:
Write a little CMake-Project just doing a:
CMake will print a warning indicating that the version of Boost may not be supported. This is caused by it not finding the config file that is provided by boost and falling back to its own. Looking at the conanfile.py of boost the reason is easy to find in the package method:
Other packages, that don't have an (probably outdated) find script delivered together with CMake are currently unusable with the cmake_paths generator.
Expected behaviour
CMake can find the packages when using the cmake_paths generator using the config scripts provided by the packages:
If there is no really! good reason that would justify deleting the cmake config files of packages and thus breaking cmake_paths, this (or a technically similar) line should be removed from all recipes that have it. I could open a pull request for this if that helps?
A grep for rmdir.*cmake to find the packages having this issue gives the following result: