在 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,因此重要的是要注意内嵌依赖包的版本代表一个完整的私有依赖图。

  • 来自消费者 conanfile.py 配方中的常规 default_options 或选项值定义不会传播到内嵌依赖包,因为它们甚至不会展开其依赖项。

  • 如果内嵌依赖包的二进制文件丢失和/或用户请求从源代码构建此类包,Conan 将失败,并引发无法构建该包的错误。

  • 要允许私有依赖项的展开,可以激活 tools.graph:vendor=build 配置。如果激活,包的私有依赖图将被计算和展开,并且包将允许构建。