根据不同选项依赖同一版本的 tool-require

注意

这是一个高级用例。在绝大多数情况下,它应该是不必要的。

在一般情况下,尝试这样做

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

将产生一个“冲突”,显示一个类似 Duplicated requirement 的错误。

然而,在某些特殊情况下,我们可能需要依赖相同版本的 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。请注意,二进制文件本身名为 mygcc1mygcc2,也就是说,它在可执行文件名称本身中包含了该选项。

我们可以为 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=Falseoptions={"myoption": value} 特性。这非常重要:我们告诉 Conan 我们实际上不需要从这些包中运行任何东西。由于 tool_requires 不可见,它们不定义头文件或库,并且它们定义了不同的 options,因此没有任何东西能让 Conan 将这两个 tool_requires 识别为冲突。因此,依赖图可以无错误地构建,并且 wine/1.0 包将包含两个不同的 tool_requires,分别指向 gcc/1.0myoption=1myoption=2

当然,我们不会从那些 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_requiresbin 文件夹将位于 PATH 中。在这种情况下,可执行文件是不同的,如 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!!