Conan 包中包含依赖项¶
警告
此功能为实验性功能,可能会有破坏性更改。更多信息请参阅Conan 稳定性部分。
从 Conan 2.4 开始,可以创建和使用完全包含其依赖项的 Conan 包,也就是说,它们会完全隐藏并隔离其依赖项与使用者。这在一些不同的场景下可能很有用。
当与其他组织共享 Conan 包时,这些组织也会包含(复制、嵌入或链接)依赖项,因此使用他们包的使用者无需访问这些依赖项,并且他们的意图是始终使用共享的预编译二进制文件。
在项目各部分之间引入硬解耦。
要使一个包包含其依赖项,请在其配方中定义以下属性:
class MyPkg(ConanFile):
name = "mypkg"
version = "0.1"
vendor = True
requires = "somedep/1.2"
当拥有此配方时,我们可以使用标准的 conan create . 来创建其二进制文件。但是,当我们将此包用作其他包的依赖项时,其依赖项将完全不可见。依赖图甚至不会展开 somedep/1.2 这个依赖项。该依赖项甚至不需要在远程仓库中可用供使用者访问,也不会进行检查。
一些重要的注意事项
包含依赖项的包旨在始终以二进制形式被使用。
包含依赖项的包的依赖项始终形成一个完全私有且隔离的依赖图,与使用该包的其余依赖图解耦。
包含依赖项的包及其使用者有责任确保包含的依赖项不会发生冲突。例如,如果一个包含依赖项的包将
libssl.a作为静态库在其包中进行常规复制,而依赖图中还有另一个提供libssl的包,那么就会发生冲突,Conan 无法检测到,因为libssl.a是作为包的内部实现细节被包含的,而不是显式建模的。可以使用provides等机制来实现此目的,但配方作者有责任考虑这一点。定义了
vendor=True的包的package_id完全独立于其依赖项。依赖项版本永远不会影响包含包的package_id,因此需要注意的是,包含包的版本代表了一个完整的私有依赖图。常规的
default_options或消费者conanfile.py配方中的选项值定义不会传播到包含包,因为它们甚至不会展开其依赖项。如果包含包的二进制文件丢失,或者用户请求从源代码构建此类包,Conan 将会失败,并引发一个错误,表明无法构建它。
要允许展开私有依赖项,可以激活
tools.graph:vendor=build配置。在这种情况下,将计算并展开包的私有依赖图,并且允许构建该包。