build_requirements()¶
build_requirements() 方法在功能上等同于 requirements() 方法，它紧随其后执行。从理论上讲，它不是严格必要的，此方法中的所有内容都可以在 requirements() 方法的末尾完成。尽管如此，build_requirements() 非常适合提供一个专门的位置来定义 tool_requires 和 test_requires。
def build_requirements(self):
self.tool_requires("cmake/3.23.5")
self.test_requires("gtest/1.13.0")
对于简单的情况，属性语法就足够了，例如 tool_requires = "cmake/3.23.5" 和 test_requires = "gtest/1.13.0"。对于条件或参数化需求，可能需要使用方法形式。
tool_requires 和 test_requires 方法只是 requires 的一个专门实例，具有一些预定义的特征值。有关特征的更多信息，请参阅 requires() 参考。
有 2 个**实验性**的 confs 可用于避免扩展这些类型的需求
tools.graph:skip_build允许完全跳过tool_requires依赖项。如果满足两个条件，则可以执行此操作：需要这些工具的包不需要从源代码构建，并且工具需求不影响使用者package_id。如果发生这种情况，Conan 将引发错误。tools.graph:skip_test允许完全跳过test_requires依赖项。如果跳过了这些依赖项，但随后需要从源代码构建某个包并且未激活tools.build:skip_test，则它将无法找到test_requires。因此，在大多数情况下，还应定义tools.build:skip_test。
请注意，如果跳过了工具和/或测试需求，它们将不会成为依赖关系图的一部分，也不会成为可能生成的锁定文件或包列表的一部分，这可能会影响未来的可重复性。此外，在大多数情况下，Conan 能够将工具和测试需求标记为不必要（Skip），避免下载大型二进制文件，只需下载通常非常快的配方即可。这意味着在大多数情况下，这些 confs 不是必需的，并且 Conan 默认值很好，请在了解权衡的情况下使用它们。
tool_requires()¶
tool_requires 等同于具有以下特征的 requires()
build=True。此依赖项处于“构建”上下文中，在构建时是必需的，但在应用程序运行时不是必需的，并将接收“构建”配置文件和配置。visible=False。对工具需求的依赖不会向下游传播。例如，一个包可以调用tool_requires("cmake/3.23.5")，但这并不意味着使用者包也使用cmake，它们甚至可以使用不同的构建系统或不同的版本，而不会导致冲突。run=True。此依赖项在构建时需要运行一些可执行文件或运行时。headers=False工具需求没有头文件。libs=False：工具需求没有使用者要链接的库（如果它有库，它们将处于“构建”上下文中，并且可能与使用者包的“主机”上下文不兼容）。
请记住，tool_requires 仅用于依赖于 cmake 或 ninja 等工具，这些工具在“构建”上下文中运行，而不是用于将链接到二进制文件的类似库的依赖项。对于库或类似库的依赖项，请使用 requires 或 test_requires。
<host_version>¶
警告
此功能处于实验阶段，可能会发生重大更改。有关更多信息，请参阅 Conan 稳定性 部分。
当您将同一个包配方用作requires和tool_requires，并且希望避免在任何用户决定覆盖host上下文中的原始requires版本时发生向下游冲突时，此语法很有用，即，用户最终可能在相同依赖项的主机和构建上下文中使用两个不同的版本。
简而言之，<host_version> 指定符允许我们确保为tool_requires解析的版本始终与主机需求的版本匹配。
例如，让我们展示一个使用protobuf的简单配方
from conan import ConanFile
class mylibRecipe(ConanFile):
name = "mylib"
version = "0.1"
def requirements(self):
self.requires("protobuf/3.18.1")
def build_requirements(self):
self.tool_requires("protobuf/<host_version>")
然后，如果任何用户想要使用mylib/0.1，但使用另一个版本的protobuf，则覆盖它不应该有任何问题
from conan import ConanFile
class myappRecipe(ConanFile):
name = "myapp"
version = "0.1"
def requirements(self):
self.requires("mylib/0.1")
self.requires("protobuf/3.21.9", override=True)
上游定义的<host_version> 确保主机和构建上下文使用相同版本的该需求。
此外，语法 <host_version:mylib> 可用于指定要跟踪的包的名称，如果requires和tool_requires具有不同的名称。例如
from conan import ConanFile
class mylibRecipe(ConanFile):
name = "mylib"
version = "0.1"
def requirements(self):
self.requires("gettext/2.31")
def build_requirements(self):
self.tool_requires("libgettext/<host_version:gettext>")
test_requires¶
test_requires 等同于具有以下特征的 requires()
test=True。此依赖项是“测试”依赖项，存在于“主机”上下文中，但并非旨在成为最终产品的一部分。visible=False。对测试需求的依赖不会向下游传播。例如，一个包可以调用self.test_requires("gtest/1.13.0")，但这并不意味着使用者包也使用gtest，它们甚至可以使用不同的测试框架，或使用具有不同版本的相同gtest，而不会导致冲突。
如果需要，可以进一步修改 tool_requires() 和 test_requires() 的各个特征，例如
def build_requirements(self):
self.tool_requires("cmake/3.23.5", options={"shared": False})
如果存在具有冲突版本的传递测试需求，则 test_requires() 允许使用 force=True 特征，同样，tool_requires() 支持 override=True 特征，用于覆盖直接工具需求的可能传递依赖项。
注意
最佳实践
tool_requires专门用于构建时工具，而不是用于将包含和链接到使用者包的库。对于具有一些特殊特征的库，请使用具有自定义特征值的requires()。self.test_requires()和self.tool_requires()方法应专门用于build_requirements()方法中，唯一的例外情况可能是requirements()方法。在任何其他方法中使用它们都是禁止的。如有必要，要在某些方法中访问有关依赖项的信息，应使用 self.dependencies 属性。