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 配置。在这种情况下，将计算和展开包的私有依赖关系图，并允许构建该包。