从conan 2.x开始conafile.py增加了一个字段package_type
,用于定义当前package的类型,
参见 package-type
如果我们在写conanfile.py时不指定这个成员,则它默认为library
不同的包类型定义默认定义不同的需求特性(Requirement traits),如下:
参见《package_type trait inferring》
关于headers,libs,run,visible,transitive_headers,transitive_libs
特性的说明参见《requirements()》
conan 允许在conanfile.py的requirements()方法中手工指定依赖包的特性。
一般来说,只要正确定义了package_type
,每个包类型提供的默认需求特性(Requirement traits)是满足大多数使用场景的。
不过conan包的头文件可见性只能传递一代,即只能传递直接引用包的项目,不能跨代传递。所以如果需要跨代传递,就要通过requirements()方法来指定transitive_headers
如下为一个conan 包 jpegwrapper的依赖树,其中common_source_cpp
的类型(package_type)为header_library
,libjpeg-turbo
和openjpege
为 library
,
如下为jpegwrapperr 测试项目的依赖定义文件conanfile.txt
[requires]
cimg/2.8.3
jpegwrapper/1.1.1-dev
[generators]
CMakeDeps
CMakeToolchain
对应的测试项目的依赖树如下
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeDeps, CMakeToolchain
from conan.tools.env import VirtualBuildEnv
class JpegwrapperConan(ConanFile):
requires="libjpeg-turbo/2.1.5","openjpeg/2.3.1","common_source_cpp/1.0.1"
会在测试项目编译时报错CImg.h
找不到jpeglib.h
,也就是turbo-jpeg
的头文件。为会这样呢?
这是因为对于library
类型的依赖包,库文件可以向下传递,但头文件对于下游默认不可见的。
而上面测试项目的依赖树中cimg这个header_library
的包中头文件引用了jpeglib.h
,所以问题就发生了。
我们详细看一下requirements()中对于transitive_headers,transitive_libs
特性的说明:
transitive_headers
If True the headers of the dependency will be visible downstream.
为True则依赖库的头文件对于下游可见transitive_libs
If True the libraries to link with of the dependency will be visible downstream.
为True则依赖库的库文件对于下游可见
再回顾一下上面《Requirement traits》章节,发现不论是static-library
还是shared-library
类型都没有定义transitive_headers
为True,即conan不会将openjpeg和turbo-jpeg的头文件传递jpegwrapper的下游调用者(consumer)。
所以CMakeDeps generator为turbo-jpeg生成的cmake配置文件中定义的import target中没有将依赖库的头文件位置定义到INTERFACE_INCLUDE_DIRECTORIES
属性,最终生成的Makefile中也就自然没有turbo-jpeg的头文件位置
要解决这个问题,就是要更新jpegwrapper的conanfile.py中对于依赖库的定义方式,通过self.requires()
方法强制指定transitive_headers=True
:
from conan import ConanFile
from conan.tools.cmake import CMake, CMakeDeps, CMakeToolchain
from conan.tools.env import VirtualBuildEnv
class JpegwrapperConan(ConanFile):
# requires="libjpeg-turbo/2.1.5","openjpeg/2.3.1","common_source_cpp/1.0.1"
def requirements(self):
self.requires("common_source_cpp/1.0.1", transitive_headers=True)
self.requires("libjpeg-turbo/2.1.5", transitive_headers=True)
self.requires("openjpeg/2.3.1", transitive_headers=True)
jpegwrapper的conanfile.py的完整代码参见 https://gitee.com/l0km/jpegwrapper/blob/master/conanfile.py
requirements()
package-type
《conan入门(一):conan 及 JFrog Artifactory 安装》
《conan入门(二):conan 服务配置-密码管理及策略》
《conan入门(三):上传预编译的库(artifact)》
《conan入门(四):conan 引用第三方库示例》
《conan入门(五):conan 交叉编译引用第三方库示例》
《conan入门(六):conanfile.txt conanfile.py的区别》
《conan入门(七):将自己的项目生成conan包》
《conan入门(八):交叉编译自己的conan包项目》
《conan入门(九):NDK交叉编译自己的conan包项目塈profile的定义》
《conan入门(十):Windows下Android NDK交叉编译Boost》
《conan入门(十一):Linux下Android NDK交叉编译Boost》
《conan入门(十二):Windows NDK 编译 boost报错:CMake was unable to find a build program … MinGW Makefile》
《conan入门(十三):conan info 命令的基本用法》
《conan入门(十四):conan new 命令的新特性–模板功能(–template)》
《conan入门(十五):AttributeError: ‘CMake‘ object has no attribute ‘definitions‘》
《conan入门(十六):profile template功能实现不同平台下profile的统一》
《conan入门(十七):支持android NDK (armv7,armv8,x86,x86_64)交叉编译的统一profile jinja2模板》
《conan入门(十八):Cannot recognize the Windows subsystem, install MSYS2/cygwin or specify a build_require》
《conan入门(十九):封装第三方开源库cpp_redis示例》
《conan入门(二十):封装只包含头文件(header_only)的库示例》
《conan入门(二十一):解决MinGW编译Openssl的编译错误:crypto/dso/dso_win32.c》
《conan入门(二十二):编译 openssl要求python 3.7以上版本》
《conan入门(二十三):Windows下MinGW编译libcurl》
《conan入门(二十四):通过CONAN_DISABLE_CHECK_COMPILER禁用编译器检查》
《conan入门(二十五):imports将包安装到本地项目或其他指定位置》
《conan入门(二十七):因profile [env]字段废弃导致的boost/1.81.0 在aarch64-linux-gnu下交叉编译失败》
《conan入门(二十八):解决conan 1.60.0下 arch64-linux-gnu交叉编译openssl/3.1.2报错问题》
《conan入门(二十九):对阿里mnn进行Conan封装塈conans.CMake和conan.tools.cmake.CMake的区别》
《conan入门(三十):对腾讯ncnn进行Conan封装》
《conan入门(三十一):在命令行(shell)中从profile中读取配置参数》
《conan 入门(三十二):package_info中配置禁用CMakeDeps生成使用项目自己生成的config.cmake》
《conan 入门(三十三):requirements()指定header的可见性(transitive_headers)》
《conan 入门(三十四):conan 2.x实现对只有Makefile的项目(erpcgen)的封装示例》