requirements()¶

requirements() 方法用于指定包的依赖项。

def requirements(self):
    self.requires("zlib/1.2.11")

对于简单的情况，可以使用属性语法，例如 requires = "zlib/1.2.11"。

依赖项特征¶

特征是依赖项子句的属性。它们确定 Conan 如何处理和传播依赖项的各个部分。特征的值通常由 Conan 基于依赖项的 package_type 计算，但也可以手动指定。

Conan 2.0 中的高级依赖项模型演示文稿提供了关于特征的良好介绍。 Advanced Dependencies Model in Conan 2.0

在下面的示例中，headers 和 libs 是特征。

self.requires("math/1.0", headers=True, libs=True)

headers¶

表示在编译时将从该包中 #included 头文件。依赖项将在主机上下文中。

libs¶

依赖项包含一些将在使用者链接时使用的库或构件。对于直接共享库和静态库，此特征通常为 True，但对于通过共享库使用的间接静态库，它可能为 false。依赖项将在主机上下文中。

build¶

此依赖项是构建工具、应用程序或可执行文件（如 cmake），仅在构建时使用。它不会链接/嵌入到二进制文件中，并且将在构建上下文中。

警告

定义 build=True 的构建时依赖项（tool_requires、build_requires）旨在与其默认的 visible=False 一起使用，目前强烈建议将其保留为 visible=False。如果您认为可能存在用例，最好先在 https://github.com/conan-io/conan/issues 中进行讨论并询问，而不是尝试启用 visible=True。

对于一些非常特殊的情况，对具有 build=True 且还定义 visible=True 的构建/工具依赖项提供了**实验性**支持，但它是实验性的，并且在未来的 Conan 版本中可能会发生重大更改。还已知并设计为不传播所有特征，例如 headers/libs 将不会传播，因为“构建”上下文中的头文件和库无法在主机上下文中链接。

run¶

此依赖项包含一些可执行文件，例如应用程序或共享库，这些文件需要能够执行（通常在路径中或其他系统环境变量中）。对于 build=False，此特征可以为 True，在这种情况下，包将包含一些可以在主机系统上安装时运行的可执行文件，通常像最终用户应用程序。对于 build=True，此特征可以为 True，包将包含在构建上下文中运行的可执行文件，通常在用于构建其他包时。

visible¶

此 require 将向下游传播，即使它不传播 headers、libs 或 run 特征。向下游传播的依赖项可能会导致版本冲突。这通常为 True，因为在大多数情况下，在同一依赖项图中存在两个不同版本的同一库至少很复杂，如果不是直接违反 ODR 或导致链接错误。它可以在高级场景中设置为 False，当我们希望在构建过程中使用同一包的不同版本时。

transitive_headers¶

如果为 True，则依赖项的头文件将对下游可见。

transitive_libs¶

如果为 True，则依赖项要链接的库将对下游可见。

test¶

此依赖项是测试库或框架，例如 Catch2 或 gtest。它主要是一个需要包含和链接的库，但不会向下游传播。

package_id_mode¶

如果配方想要指定依赖项版本如何影响当前包的 package_id，可以在这里直接指定。

虽然它也可以在 package_id() 方法中完成，但在 requires 中指定它似乎更简单，并且避免了一些歧义。

# We set the package_id_mode so it is part of the package_id
self.tool_requires("tool/1.1.1", package_id_mode="minor_mode")

这等效于

def package_id(self):
  self.info.requires["tool"].minor_mode()

force¶

此 requires 将强制其版本在依赖项图的上游，覆盖其他现有版本，即使是传递依赖项的版本，并解决潜在的现有冲突。下游使用者的 force 特征始终具有更高的优先级。

override¶

与 force 特征相同，但不添加 direct 依赖项。如果没有传递依赖项要覆盖，则此 require 将被丢弃。此特征仅在定义 requires 时存在，但在图完全评估后，它将不再作为实际的 requires 存在。

注意

最佳实践

不建议将 force 和 override 特征作为解决冲突的通用版本控制方案，而只是作为解决版本冲突的临时解决方法。应尽可能避免使用它，并且建议更新图中的版本或版本范围以避免冲突，而无需使用覆盖和强制。

direct¶

如果依赖项是直接依赖项，即它是由当前配方显式声明的，或者它是传递依赖项。

options¶

可以将依赖项的选项值定义为特征。

self.requires("mydep/0.1", options={"dep_option": "value"})

警告

在配方中定义选项值没有强保证，请查看此关于依赖项选项值的常见问题解答。定义选项值的推荐方法是在配置文件中。

包类型特征推断¶

如果配方没有显式设置，则某些特征会根据 package_type 的值自动推断。

application: headers=False, libs=False, run=True

shared-library: run=True

static-library: run=False

header-library: headers=True, libs=False, run=False

build-scripts: headers=False, libs=False, run=True, visible=False

此外，基于被依赖者的 package_type，在上述提到的基础上推断一些额外的特征。

header-library: transitive_headers=True, transitive_libs=True

每种依赖类型的默认特征¶

每种类型在上一节中所述的基础上，默认设置了一些额外的特性。这些特性是：

requires: build=False

build_requires: headers=False, libs=False, build=True, visible=False

tool_requires: headers=False, libs=False, build=True, run=True, visible=False

test_requires: headers=True, libs=True, build=False, visible=False, test=True