依赖于工具要求的相同版本，但具有不同的选项¶

注意

这是一个高级用例。在绝大多数情况下，这都不是必需的。

通常情况下，尝试执行类似的操作

def build_requirements(self):
    self.tool_requires("gcc/1.0")
    self.tool_requires("gcc/1.0")

将会生成一个“冲突”，显示类似 重复依赖项 的错误。

然而，在某些特殊情况下，我们可能需要依赖于相同的 tool_requires 版本，但使用该 tool_requires 的不同二进制文件。可以通过向这些 tool_requires 传递不同的 options 来实现。请先克隆源代码以重现此项目。你可以在 GitHub 上的 examples2 仓库中找到它们

git clone https://github.com/conan-io/examples2.git
cd examples2/examples/graph/tool_requires/different_options

在那里，我们有一个假的 gcc 配方，其中

class Pkg(ConanFile):
    name = "gcc"
    version = "1.0"
    options = {"myoption": [1, 2]}

    def package(self):
        # This fake compiler will print something different based on the option
        echo = f"@echo off\necho MYGCC={self.options.myoption}!!"
        save(self, os.path.join(self.package_folder, "bin", f"mygcc{self.options.myoption}.bat"), echo)
        save(self, os.path.join(self.package_folder, "bin", f"mygcc{self.options.myoption}.sh"), echo)
        os.chmod(os.path.join(self.package_folder, "bin", f"mygcc{self.options.myoption}.sh"), 0o777)

这不是一个真正的编译器，它通过一个 shell 或 bat 脚本来模拟，该脚本在执行时会打印 MYGCC=current-option。请注意，二进制文件本身名为 mygcc1 和 mygcc2，也就是说，它在可执行文件名本身中包含该选项。

我们可以为 gcc/1.0 创建 2 个不同的二进制文件，如下所示

$ conan create gcc -o myoption=1
$ conan create gcc -o myoption=2

现在，在 wine 文件夹中，有一个 conanfile.py 如下所示

class Pkg(ConanFile):
    name = "wine"
    version = "1.0"

    def build_requirements(self):
        self.tool_requires("gcc/1.0", run=False, options={"myoption": 1})
        self.tool_requires("gcc/1.0", run=False, options={"myoption": 2})

    def generate(self):
        gcc1 = self.dependencies.build.get("gcc", options={"myoption": 1})
        assert gcc1.options.myoption == "1"
        gcc2 = self.dependencies.build.get("gcc", options={"myoption": 2})
        assert gcc2.options.myoption == "2"

    def build(self):
        ext = "bat" if platform.system() == "Windows" else "sh"
        self.run(f"mygcc1.{ext}")
        self.run(f"mygcc2.{ext}")

第一点很重要是 build_requirements() 方法，它对两个二进制文件都执行 tool_requires()，但定义了 run=False 和 options={"myoption": value} 特性。这非常重要：我们告诉 Conan 我们实际上不需要运行任何来自这些包的内容。由于 tool_requires 不可见，它们不定义头文件或库，并且它们定义了不同的 options，因此没有任何内容使 Conan 将这两个 tool_requires 识别为冲突。因此，依赖关系图可以在没有错误的情况下构建，并且 wine/1.0 包将包含 2 个不同的工具要求，分别指向具有 myoption=1 和 myoption=2 的 gcc/1.0。

当然，并非我们不会运行任何来自这些 tool_requires 的内容，但现在 Conan 不知道这一点，并且完全由用户负责管理它。

警告

使用 run=False 使 tool_requires() 完全不可见，这意味着配置文件 [tool_requires] 将无法覆盖其版本，但它会创建一个带有从配置文件注入的版本的新工具要求依赖项。你可能需要使用类似 !wine/*: gcc/3.0 的内容来排除特定的包。

该配方仍然可以在 generate() 方法中访问每个不同的 tool_require 版本，只需提供我们想要的依赖项的选项值即可，例如 self.dependencies.build.get("gcc", options={"myoption": 1})。

最后，最重要的一点是，这些工具的使用完全由用户负责。由于默认情况下 VirtualBuildEnv 生成器会更新 PATH 环境变量，因此两个 tool_requires 的 bin 文件夹（包含可执行文件）将在路径中。在这种情况下，可执行文件不同，例如 mygcc1.sh 和 mygcc2.sh，因此没有问题，每个可执行文件都将在其包内找到。

但是，如果可执行文件完全相同，例如 gcc.exe，那么有必要在 generate() 方法中获取完整的文件夹，例如 self.dependencies.build.get("gcc", options={"myoption": 1}).cpp_info.bindir 并使用完整路径进行区分。

让我们看看它是否有效。如果我们执行

$ conan create wine
...
wine/1.0: RUN: mygcc1.bat
MYGCC=1!!

wine/1.0: RUN: mygcc2.bat
MYGCC=2!!