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 的一个特例，并带有一些预定义的 trait 值。有关 trait 的更多信息，请参阅 requires() 参考。
有两个实验性的 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()，并带有以下 trait：
build=True。此依赖项位于“build”上下文中，在构建时是必需的，但在应用程序运行时不是必需的，并且将接收“build”配置文件和配置。visible=False。对工具依赖项的依赖不会向下传播。例如，一个包可以调用tool_requires("cmake/3.23.5")，但这并不意味着消费者包也使用cmake，它们甚至可以使用不同的构建系统或不同版本，而不会引起冲突。run=True。此依赖项包含一些在构建时需要运行的可执行文件或运行时。headers=False。工具依赖项没有头文件。libs=False：工具依赖项没有供消费者链接的库（如果它有库，它们将位于“build”上下文中，并且可能与消费者的“host”上下文不兼容）。
请注意，tool_requires 仅用于依赖 cmake 或 ninja 等工具，这些工具在“build”上下文中运行，而不是用于将被链接到二进制文件中的类库依赖项。对于库或类库依赖项，请使用 requires 或 test_requires。
<host_version>¶
警告
此功能是实验性的，可能会发生重大更改。有关更多信息，请参阅 Conan 稳定性 部分。
当您将相同的包配方用作 requires 和 tool_requires，并且想避免下游发生冲突（如果用户决定在 host 上下文中覆盖原始 requires 版本），则此语法很有用。也就是说，用户最终可能会在同一依赖项的 host 和 build 上下文中得到两个不同版本。
简而言之，<host_version> 说明符允许我们确保为 tool_requires 解析的版本始终与 host 依赖项的版本匹配。
例如，我们来看一个使用 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 和 build 上下文使用相同版本的该依赖项。
此外，可以使用语法 <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()，并带有以下 trait：
test=True。此依赖项是“test”依赖项，存在于“host”上下文中，但并非旨在成为最终产品的一部分。visible=False。对测试依赖项的依赖不会向下传播。例如，一个包可以调用self.test_requires("gtest/1.13.0")，但这并不意味着消费者包也使用gtest，它们甚至可以使用不同的测试框架，或使用相同gtest的不同版本，而不会引起冲突。
警告
由于 test_requires 定义了 visible=False trait，因此必须小心，避免与正在作为测试依赖项使用的同一包的正常依赖项产生传递性依赖项。这是因为具有直接 visible=False 依赖项的包可能会在传递性依赖项对当前配方正在作为测试依赖项请求的同一包具有 visible=True 依赖项时产生冲突。在这些情况下，当不同的可见性规则到达同一个包时，可见的传递性依赖项将被使用并向下传播。
如果需要，可以进一步修改 tool_requires() 和 test_requires() 的各个 trait，例如：
def build_requirements(self):
self.tool_requires("cmake/3.23.5", options={"shared": False})
test_requires() 在存在版本冲突的传递性测试依赖项的情况下支持 force=True trait，同样，tool_requires() 支持 override=True trait，用于覆盖直接工具依赖项可能存在的传递性依赖项。
注意
最佳实践
tool_requires仅用于构建时工具，而不是用于包含并链接到消费者包中的库。对于具有某些特殊特征的库，请使用带有自定义 trait 值的requires()。self.test_requires()和self.tool_requires()方法应仅在build_requirements()方法中使用，唯一可能的例外是requirements()方法。在任何其他方法中使用它们是被禁止的。要在某些方法中访问有关依赖项的信息，应使用 self.dependencies 属性。