Conan 1.33.0 是一个重大的版本！我们在配置文件中引入了一个名为 [conf] 的新部分，以及一个名为 global.conf 的相应配置文件，以便全局设置相关值。我们改进了对 Qbs 的支持，提供了一个新的工具链和构建助手，以及一个新的 Meson 构建助手。我们添加了一个名为 CMakeDeps 的新生成器，并更新了“build_modules”策略以支持为不同的生成器传递不同的构建模块。在随处可见的 tools.get() 函数中添加了一个新的 strip_root 参数，并且还将其添加到 tools.unzip() 和 tools.untargz() 的相关函数中。我们现在还在 macOS 下添加了两个新的子设置：sdk 和 subsystem，后者用于支持 Mac Catalyst。

配置文件中新的 [conf]iguration 部分和 global.conf

在此版本中，Conan 添加了一些新的配置功能。由于各种原因，conan.conf 不适合用于这些配置的全局定义，因此我们专门为此目的在 Conan 用户主目录中引入了一个新文件。

global.conf

目前，此文件的主要目的是为名为 [conf] 的新配置文件块定义全局值。[conf] 功能为用户提供了一种新的方法来将参数传递给 Conan recipes 和 Conan 提供的工具。默认情况下，[conf] 参数和值不会影响 package_id，因此它与配置文件的 [env] 块非常相似。但是，最大的区别在于 [conf] 从逻辑上专门用于声明和指定 Conan 行为的参数，而 [env] 块实际上是为声明和指定 Conan 调用的其他命令行工具（如构建脚本、构建系统、编译器、链接器等）的参数而设计的。

您可以使用 [conf] 声明任意变量和值，并以 user 命名空间作为前缀。请注意，您可以定义一个应用于所有软件包的值，然后像 [env] 部分一样按每个软件包定义值。同样，这可以在配置文件或 global.conf 中定义。

[conf]
user.mycompany.logging:print_all_env_vars=False
mypkg:user.logging:print_all_env_vars=True

在这里，您可以看到我们使用了 mycompany 的子命名空间，建议在所有自定义使用 [conf] 时使用它，以避免将来可能发生冲突。然后，您可以在您的 recipes 中像这样使用这些变量和值。

class Pkg(ConanFile):
    name = "mypkg"

    def build(self):
        if(self.conf["user.mycompany.logging:print_all_env_vars"]):
            for param in os.environ.keys():
                self.output.info("%s=%s" % (param, os.environ[param]))
                # Will print all env vars defined at build as "key=value" pairs

但是，除了为 Conan recipe 作者提供一种从 recipes 中公开参数的新功能外，[conf] 功能还用于公开 Conan 的 tools 命名空间中内置的 Conan 类和函数的参数。这包括 build_helpers、generators、toolchains 和其他自由函数。例如，我们已使用它来公开 MSBuild 的详细程度设置。如下例所示，我们使用工具或函数的完整命名空间（在本例中为 tools.microsoft.msbuild_verbosity）公开此类 conf 项目。

[conf]
tools.microsoft:msbuild_verbosity = Quiet
mypkg:tools.microsoft:msbuild_verbosity = Normal
mypkg2:tools.microsoft:msbuild_verbosity = Diagnostic

最后，我们还使用它在 core 命名空间下公开了一些与 Conan 的“核心”行为相关的参数。

core:required_conan_version = "expression"
core.package_id:msvc_visual_incompatible

在学习此新功能时，许多人首先会问：“什么时候应该使用 [conf] 而不是 [settings] 或 [options]？”

关键因素是参数是否会影响二进制文件，因为 [conf] 默认情况下不会影响 package_id（注意：我们正在考虑使能够根据需要选择 [conf] 是否影响 package_id）。例如，优化级别不适合通过 [conf] 公开，因为不同的值会导致不同的二进制文件。除了 verbosity 之外，其他适合的示例包括要使用的处理器数量、是否并行构建、生成日志文件的路径等。在我们正在实施的内置用法之外，我们建议的最常见用法是替换人们使用环境变量为 recipes 实现非二进制影响参数的情况。

总而言之，[conf] 功能在其实现中仍然非常新，我们希望在即将发布的版本中添加更多内容（最重要的是，CLI 参数支持）。尽管如此，我们知道可能存在一些我们尚未想到但 [conf] 可以扩展以解决的用例。如果您认为您有一个可能适合 conf 的用例，请通过打开 github 问题 告知我们。

tools.get() 中新的 strip_root 参数

名为 tools.get() 的函数已经存在很长时间了，它使获取软件包的源代码文件变得非常方便。它通过提供一个单一函数来实现此目的，该函数

  • 下载源代码
  • 自动检测它是压缩的 .zip 或 .tar.gz 文件
  • 使用相应的工具自动提取内容

许多源代码存档的一个不幸细节是，存档内部通常有一个“根目录”，所有文件都位于该目录中。因此，提取后，会出现一个额外的文件夹层，其中包含一些需要以某种方式管理的名称。无论如何管理，它都会导致 recipe 中出现额外的代码行，通常必须在源代码和构建方法中显式引用目录名称。

tools.get() 现在为我们提供了一种更好的方法！通过传递 strip_root=True 参数，解压缩过程将理解此根目录是不必要的，并且在提取源代码后它将不存在。

值得注意的是，tools.get() 在内部依赖于另外两个公共 tools 函数，这两个函数现在也支持相同的参数。总而言之，以下是三个受影响的函数签名。

  • tools.get(...., strip_root=True)
  • tools.unzip(...., strip_root=True)
  • tools.untargz(...., strip_root=True)

新的 Meson、Qbs 和 CMake 集成

对于 Qbs 构建系统，我们添加了一个新的 toolchain 和 build_helper，它们利用了我们新的构建系统集成模型。您可以在您的 recipes 中像这样使用它们。

from conan.tools.qbs import Qbs, QbsToolchain

class Pkg(ConanFile):

    def generate(self):
        tc = QbsToolchain(self)
        tc.generate()

    def build(self):
        qbs = Qbs(self)
        qbs.build()

对于 Meson，我们已经有了一个工具链类，但此版本为其引入了 build_helper。因此，现在的用法与上面的 Qbs 相同。

from conan.tools.cmake import Meson, MesonToolchain

class Pkg(ConanFile):

    def generate(self):
        tc = MesonToolchain(self)
        tc.generate()

    def build(self):
        meson = Meson(self)
        meson.build()

此外，我们长期以来一直拥有许多 CMake 集成，包括工具链、构建助手和众多生成器。在此版本中，我们添加了另一个名为 CMakeDeps 的生成器。实际上，它只是 cmake_find_package_multi 使用了新的名称和命名空间，并利用了新的集成模型。它与工具链和构建助手一起使用。

from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps

class Pkg(ConanFile):

    def generate(self):
        tc = CMakeToolchain(self)
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

cpp_info 上的每个生成器 build_modules

我们正在继续改进支持的另一个集成点是使用其他构建系统文件，例如 CMake 的 .cmake 文件。组织可能在 Conan 之前就使用过这些文件，或者可能有一些特殊用例，这些用例使在这些外部文件中声明变量比在 Conan 的 cpp_info 数据结构中定义变量具有一些优势。

无论如何，我们已经有一段时间了，我们有一个仅支持 CMake 的实验性实现。在此版本中，我们使其能够通过更改语法来支持任意数量的构建系统。以下是一个新语法的示例。

    self.cpp_info.build_modules["cmake_find_package"].append("cmake/myfunctions.cmake")

cpp_info.build_modules 现在支持获取一个字典，其中键是应将 build_module include() 到的生成器的名称，值是要 include() 的文件的路径列表。

目前，我们只实现了将其包含到 CMake 生成器中的功能，但将来，我们希望实现对所有生成器的支持。如果您有一个希望使用此功能支持的构建系统，请打开一个 Github 问题以请求它。

设置中的新 msvc 编译器

此版本标志着 Conan 二进制建模策略中另一个主要迁移过程的开始。我们现在添加了一个名为 msvc 的新编译器。实际上，正如您可能猜到的那样，长期目标因此最终替换 Conan 设置中 Visual Studio 的编译器名称。

此外，此设置还提供了 compiler.version 和 compiler.runtime 的新模型。对于版本，msvc 现在模拟实际的编译器可执行文件版本，而不是 IDE 版本。对于运行时，以前是 compiler.runtime，现在被分成 compiler.runtime 和 compiler.runtime_type。

因此，旧的语法是

compiler="Visual Studio"
compiler.version=16
compiler.runtime=MDd

新编译器模型的等效语法是

compiler=msvc
compiler.version=19.1
compiler.runtime=dynamic
compiler.runtime_type=Debug

此功能的时间线是，我们希望它在 Conan 1 的未来版本中稳定下来，并在 Conan 2.0 中成为默认模型。这包括在 Conan 2.0 中完全移除 Visual Studio 生成器。因此，越多的用户提前迁移到此生成器并提供反馈，对 Conan 2.0 就越有利。

改进对 Apple 平台的支持

Apple 持续为开发者发布新的和不同的平台和选项，Conan 也在持续跟踪这些变化。我们通过在 Macos 下添加 subsystem 的子集，并向其中添加 catalyst 选项，从而增加了对 Mac Catalyst 的支持。此外，为了让开发者能够正确区分为嵌入式 Apple 平台构建的二进制文件和为其模拟器构建的二进制文件，我们在以下每个与 Apple 相关的 os 设置下添加了 sdk 的子集

    Macos:
        version: ...
        sdk: [None, "macosx"]
        subsystem: [None, "catalyst"]
    iOS:
        version: ...
        sdk: [None, "iphoneos", "iphonesimulator"]
    watchOS:
        version: ...
        sdk: [None, "watchos", "watchsimulator"]
    tvOS:
        version: ....
        sdk: [None, "appletvos", "appletvsimulator"]


除了上面列出的内容之外，还有一长串相当重要的错误修复，您可能希望了解。如果是这样，请参阅 更改日志 以获取完整列表。

我们希望您喜欢此版本，并期待您提供反馈。