依赖同个 tool-require 的不同版本

注意

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

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

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

会产生“冲突”,并显示类似 Duplicated requirement 的错误。在大多数情况下,这是正确的,因为显而易见的是,不能使用同一编译器的两个版本来构建当前包。

但是,在某些特殊情况下,可能会希望这样做。让我们重现一下潜在的场景。请先克隆源代码来重现这个项目。您可以在 GitHub 上的 examples2 仓库 中找到它们。

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

在那里,我们有一个 gcc 的伪造 recipe,其中包含

class Pkg(ConanFile):
    name = "gcc"

    def package(self):
        echo = f"@echo off\necho MYGCC={self.version}!!"
        save(self, os.path.join(self.package_folder, "bin", f"mygcc{self.version}.bat"), echo)
        save(self, os.path.join(self.package_folder, "bin", f"mygcc{self.version}.sh"), echo)
        os.chmod(os.path.join(self.package_folder, "bin", f"mygcc{self.version}.sh"), 0o777)

这不是一个实际的编译器,它用一个 shell 或 bat 脚本来模拟,当执行时,它会打印 MYGCC=current-version。请注意,二进制文件本身被称为 mygcc1.0mygcc2.0,也就是说,它在可执行文件名本身中包含了版本。

我们可以使用以下命令为 gcc/1.0gcc/2.0 创建两个不同的版本:

$ conan create gcc --version=1.0
$ conan create gcc --version=2.0

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

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

    def build_requirements(self):
        # If we specify "run=False" they no longer conflict
        self.tool_requires("gcc/1.0", run=False)
        self.tool_requires("gcc/2.0", run=False)

    def generate(self):
        # It is possible to individually reference each one
        gcc1 = self.dependencies.build["gcc/1.0"]
        assert gcc1.ref.version == "1.0"
        gcc2 = self.dependencies.build["gcc/2.0"]
        assert gcc2.ref.version == "2.0"

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

第一个要点是 build_requirements() 方法,它执行一个 tool_requires() 到两个版本,但定义了 run=False这非常重要:我们告诉 Conan 我们实际上不需要运行这些包中的任何东西。由于 tool_requires 不可见,它们不定义头文件或库,Conan 没有理由识别这两个 tool_requires 是冲突的。因此,依赖图可以无错误地构建,并且 wine/1.0 包将包含两个不同的 tool-require,分别指向 gcc/1.0gcc/2.0

当然,说我们不会运行这些 tool_requires 中的任何东西是不真实的,但现在 Conan 并不知道这一点,这完全是用户的责任。

警告

使用 run=False 会使 tool_requires() 完全不可见,这意味着配置文件 [tool_requires] 将无法覆盖其版本,但它会创建一个额外的 tool-require 依赖项,其中注入了来自配置文件的版本。您可能想排除特定的包,例如使用 !wine/*: gcc/3.0

generate() 方法中,recipe 仍然可以通过提供完整的引用,例如 self.dependencies.build["gcc/1.0"],来访问每个不同的 tool_require 版本。

最后,最重要的一点是,这些工具的使用完全由用户负责。包含可执行文件的两个 tool_requiresbin 文件夹将由于 `VirtualBuildEnv` 生成器而添加到 PATH 中,该生成器默认更新 PATH 环境变量。在这种情况下,可执行文件是不同的,例如 mygcc1.0.sh```和 ``mygcc2.0.sh,所以这不是问题,每个可执行文件都会在其包内找到。

但是,如果可执行文件完全相同,例如 gcc.exe,那么就有必要在 generate() 方法中(通常是这样)使用类似 self.dependencies.build["gcc/1.0"].cpp_info.bindir 的方式获取完整文件夹,并使用完整路径来消除歧义。

让我们看看它是如何工作的。如果我们执行

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

wine/1.0: RUN: mygcc2.0.bat
MYGCC=2.0!!