CustomCMakeUtils conan package that provides CMake module which includes commonly used cmake macros and functions.
from conan import ConanFile
class CustomCMakeUtils Conan(ConanFile):
name = "CustomCMakeUtils "
description = "CMake utils for components."
version = "0.1"
cmake_modules = ['CustomUtils.cmake']
exports_sources = cmake_modules
def package_id(self):
del self.info.settings.os
del self.info.settings.arch
del self.info.settings.compiler
del self.info.settings.build_type
def package(self):
for module in self.cmake_modules:
self.copy(module)
def package_info(self):
# old cmake_find_package generators
self.cpp_info.build_modules = self.cmake_modules
# cmake 2.0, CMakeDeps generator
self.cpp_info.set_property("cmake_build_modules", self.cmake_modules)
Conan Package that relies on CustomCMakeUtils, using find_package(CustomCMakeUtils REQUIRED) in its top level CMakeLists.txt.
Logs (Executed commands with output) (Include/Attach if Applicable)
Runningn with both, host and build profile, doesn't generate the CustomCMakeUtils cmake module, which will result in a CMake error during conan build .
When only specifying the host profile the CustomCMakeModule is available and the build succeeds:
app$ conan install . -pr:h default -b missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux
os.platform=Project.Debian
os_build=Linux
[options]
[build_requires]
*: CustomCMakeUtils/0.1@fjp/stable
[env]
conanfile.py (app/None): Installing package
Requirements
Packages
Build requirements
CustomCMakeUtils/0.1@fjp/stable from 'my-remote' - Cache
Build requirements packages
CustomCMakeUtils/0.1@fjp/stable:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
Installing (downloading, building) binaries...
CustomCMakeUtils/0.1@fjp/stable: Already installed!
conanfile.py (app/None): Applying build-requirement: CustomCMakeUtils/0.1@fjp/stable
conanfile.py (app/None): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (app/None): Generator 'CMakeDeps' calling 'generate()'
conanfile.py (app/None): Generator txt created conanbuildinfo.txt
conanfile.py (app/None): Calling generate()
conanfile.py (app/None): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
conanfile.py (app/None): Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
conanfile.py (app/None): If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake <path> -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/fjp/dev/app/build/generators/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
conanfile.py (app/None): Aggregating env generators
conanfile.py (app/None): Generated conaninfo.txt
conanfile.py (app/None): Generated graphinfo
app$ ls build/generators/
cmakedeps_macros.cmake conan_toolchain.cmake CustomCMakeUtilsConfigVersion.cmake CustomCMakeUtils-Target-release.cmake
CMakePresets.json CustomCMakeUtilsConfig.cmake CustomCMakeUtils-release-x86_64-data.cmake CustomCMakeUtilsTargets.cmake
A workaround for this is to use self.requires("CustomCMakeUtilsTargets/0.1@fjp/stable") in the app recipe. Is there a reason why this is not working in the [tool_requires] section of the profiles and having both host and build profiles set?
Another question is about the name of test_requires(): CustomCMakeUtilsTargets isn't really suitable for the self.requires method as it is only used during build time for CMake. However, setting it as a requirement through self.test_requires doesn't make any sense either as it is not test related. self.build_requires would convey perfect meaning but that is going to be removed^rem:
Note: The test_requires(), available from Conan 1.43, is equivalent to the previous self.build_requires(, force_host_context=True) syntax. As the later is going to dissapear in Conan 2.0, the former test_requires() form is recommended.
What is the recommended way of reusing CMake macros, functions etc? And is there a chance that self.build_requires stays?
I think the issue is explained in the documentation, but this is applicable to conanfile.py. With conanfile.txt you might have to define it in both requires and tool_requires.
Hello Conan Team
Environment Details (include every applicable attribute)
Steps to reproduce (Include if Applicable)
Use a host and build profiles such as
CustomCMakeUtils conan package that provides CMake module which includes commonly used cmake macros and functions.
Conan Package that relies on CustomCMakeUtils, using
find_package(CustomCMakeUtils REQUIRED)
in its top level CMakeLists.txt.Logs (Executed commands with output) (Include/Attach if Applicable)
Runningn with both, host and build profile, doesn't generate the CustomCMakeUtils cmake module, which will result in a CMake error during
conan build .
When only specifying the host profile the CustomCMakeModule is available and the build succeeds:
A workaround for this is to use
self.requires("CustomCMakeUtilsTargets/0.1@fjp/stable")
in the app recipe. Is there a reason why this is not working in the[tool_requires]
section of the profiles and having both host and build profiles set?Another question is about the name of
test_requires()
: CustomCMakeUtilsTargets isn't really suitable for theself.requires
method as it is only used during build time for CMake. However, setting it as a requirement throughself.test_requires
doesn't make any sense either as it is not test related.self.build_requires
would convey perfect meaning but that is going to be removed^rem:What is the recommended way of reusing CMake macros, functions etc? And is there a chance that
self.build_requires
stays?