在 Conan 包中整合依赖

警告

此功能为实验性,并可能发生重大变更。详情请参阅 Conan 稳定性 部分。

从 Conan 2.4 开始,可以创建和使用完全整合(vendoring)其依赖项的 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 配置。如果激活此配置,包的私有依赖图将被计算并展开,并且该包将被允许构建。