requirements()¶
requirements()
方法用于指定包的依赖项。
def requirements(self):
self.requires("zlib/1.2.11")
对于简单情况,可以使用属性语法,例如 requires = "zlib/1.2.11"
。
依赖项特性¶
特性(Traits)是 `requires` 子句的属性。它们决定了 Conan 如何处理和传播依赖项的各个部分。特性的值通常由 Conan 根据依赖项的 package_type 计算得出,但也可以手动指定。
关于特性的良好介绍可在 Conan 2.0 中的高级依赖项模型 演示文稿中找到。
在下面的示例中,headers
和 libs
是特性。
self.requires("math/1.0", headers=True, libs=True)
headers¶
表示此包在编译时将 #include
头文件。该依赖项将位于主机(host)环境中。
libs¶
该依赖项包含一些库或构件,这些库或构件将在消费方链接时使用。此特性对于直接的共享库和静态库通常为 True
,但对于通过共享库使用的间接静态库可能为 False
。该依赖项将位于主机(host)环境中。
build¶
此依赖项是一个构建工具、应用程序或可执行文件(如 CMake),仅在构建时使用。它不会链接/嵌入到二进制文件中,并将位于构建(build)环境中。
警告
定义了 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
将不会被传播,因为来自“构建”上下文的头文件和库无法在主机(host)上下文中链接。
run¶
此依赖项包含一些可执行文件,可以是应用程序或共享库,它们需要可用于执行(通常在 PATH 或其他系统环境变量中)。当 build=False
时,此特性可以为 True
,在这种情况下,包将包含一些在安装时可在主机系统上运行的可执行文件,通常就像一个最终用户应用程序。当 build=True
时,此特性可以为 True
,包将包含在构建(build)环境中运行的可执行文件,通常在用于构建其他包时。
visible¶
此 require
将向下游传播,即使它不传播 headers
、libs
或 run
特性。向下游传播的依赖项可能导致版本冲突。这通常为 True
,因为在大多数情况下,在同一依赖图中使用同一库的两个不同版本至少是复杂的,如果不是直接违反 ODR 或导致链接错误的话。在高级场景中,当我们需要在构建期间使用同一包的不同版本时,可以将其设置为 False
。
警告
visible
特性可能导致冲突,如果一个传递性依赖项对当前配方声明为 visible=False
的同一包具有 visible=True
的依赖项。在这种不同可见性规则作用于同一包的情况下,将使用可见的传递性依赖项并向下游传播。
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
特性作为通用的版本控制解决方案来解决冲突,而仅将其作为解决版本冲突的临时性方法。应尽可能避免使用它们,推荐的方法是更新图中的版本或版本范围以避免冲突,而无需覆盖和强制。一个关键点是,
override
特性不会从您的包创建直接依赖项,而force
特性会。这意味着override
特性仅在您想要覆盖某个传递性依赖项的版本,同时不向其添加直接依赖项时有用。
direct¶
如果依赖项是直接的,即它已由当前配方明确声明,或者它是传递性的。
options¶
可以将依赖项的选项值定义为一个特性
self.requires("mydep/0.1", options={"dep_option": "value"})
警告
在配方中定义选项值没有强有力的保证,请查看 有关依赖项选项值的常见问题解答。推荐定义选项值的方式是在配置文件中。
no_skip¶
此特性是 Conan 2.16 中引入的实验性功能,可能存在破坏性变更。更多信息请参阅Conan 稳定性部分。
当不需要时,Conan 能够避免下载传递性依赖项的包二进制文件。例如,如果一个包含可执行文件的 package_type = "application"
包依赖于(requires
)另一个 package_type = "static-library"
的包(或一个常规库,但选项为 shared=False
),那么安装应用程序包的二进制文件不需要静态库依赖项的二进制文件来工作。Conan 将“跳过”这些二进制文件的下载,从而节省了下载和安装的时间和传输成本。这些二进制文件在 Conan 命令输出中被标记为“Skipped binaries”(跳过的二进制文件)。
tools.graph:skip_binaries
配置可以更改默认行为,如果设置为 False
,它将避免跳过二进制文件,这在某些情况下可能很有用。
no_skip=True
特性可以在依赖项中定义,例如
name = "mypkg"
def requirements(self):
self.requires("mydep/0.1", no_skip=True)
当 mypkg
的二进制文件必要时,这将强制下载 mydep/0.1
的二进制文件。
注意
最佳实践
no_skip=True
的使用应该是例外情况,仅限于非常有限和特殊的使用场景,默认的 Conan “跳过二进制文件”行为对于绝大多数情况应该都是适用的。通常,单独使用它没有意义,但如果与其他特性(如 visible=False
)一起使用,则可能有用。除非绝对必要,否则请避免使用它,并且它应仅在非常特殊的配方中使用。如果它在许多配方中使用,则很可能是一种滥用。
package_type 特性推断¶
如果配方没有明确设置,某些特性会根据 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