requirements()¶

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

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

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

依赖项特性¶

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

关于特性的良好介绍在 Conan 2.0 中的高级依赖项模型演示文稿中提供。

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

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

headers¶

指示存在将在编译时从此包 #included 的头文件。依赖项将在宿主上下文中。

libs¶

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

build¶

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

警告

构建时需求（tool_requires, build_requires）定义了 build=True，旨在与它们的默认 visible=False 一起使用，并且目前强烈建议将它们保持为 visible=False。如果您认为您可能有使用场景，最好先在 https://github.com/conan-io/conan/issues 中讨论并询问，而不是尝试启用 visible=True。

对于某些非常特殊的情况，实验性支持使用 build=True 的构建/工具 requires，它们也定义了 visible=True，但这只是实验性的，并且在未来的 Conan 版本中可能会有破坏性更改。众所周知，它也被设计为不传播所有特性，例如 headers/libs 将不会被传播，因为来自“build”上下文的 headers 和 libs 无法在宿主上下文中链接。

run¶

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

visible¶

即使它不传播 headers、libs 或 run 特性，此 require 也将向下游传播。向下游传播的需求可能会导致版本冲突。这通常为 True，因为在大多数情况下，在同一依赖关系图中拥有同一库的 2 个不同版本至少是复杂的，如果不是直接违反 ODR 或导致链接错误。在高级场景中，当我们想在构建期间使用同一包的不同版本时，可以将其设置为 False。

transitive_headers¶

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

transitive_libs¶

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

test¶

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

package_id_mode¶

如果 recipe 想要指定依赖项版本如何影响当前包 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 特性作为通用的版本控制解决方案，而仅作为解决版本冲突的临时解决方法。应尽可能避免使用它，并且建议更新图中的版本或版本范围，以避免在没有 overrides 和 forces 的情况下发生冲突。
一个关键的要点是，override 特性不会从您的包创建直接依赖项，而 force 特性会。这意味着 override 特性仅在您想要覆盖其中一个传递依赖项的版本，同时不向其添加直接依赖项时才有用。

direct¶

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

options¶

可以为依赖项定义选项值作为特性

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

警告

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

package_type 特性推断¶

如果 recipe 没有显式设置，则某些特性会根据 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 的默认特性¶

每种 requires 默认情况下都会在上一节所述的特性之上设置一些额外的特性。这些特性是

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