Conan 1.35 添加了许多新功能。在开始讨论它们之前，我们必须强调以下事实：它们几乎都是**实验性的**，其中许多在 Conan 2.0 发布之前不会脱离**实验性**状态。在接下来的几个版本中，这种情况也可能会持续存在。我们正在添加新的原始**实验性**抽象，在这些抽象之上重构现有的**实验性**功能，然后在这些功能之上添加新的**实验性**功能。这是一大堆实验。话虽如此，我们绝对不建议在生产配方或工作流程中使用这些功能一段时间。

面向 Conan 2.0 的新的 conan.tools.files 命名空间

新的 conan.tools.files 命名空间目前仅包含两个已记录的功能

  • patch()（改进）
  • apply_conandata_patches()（新增）

但是，该命名空间旨在成为所有与文件操作相关的现有实用程序函数的新家园，包括

  • mkdir()
  • load()
  • save()
  • download()
  • ftp_download()

但是，必须指出的是，我们还发现需要重构几乎所有这些与文件相关的函数并更改其函数签名。我们不希望破坏现有的函数，因此我们正在利用“命名空间重定位过程”作为提供具有新签名的函数的机会。可能需要几个版本才能重构此命名空间中的这些其他函数并将其视为“稳定”，因此请继续关注。

直接从 Lockfile 安装包

我们收到的针对那些正在尝试使用 Conan 的“lockfile”功能的用户提出的最主要的功能请求之一是，仅使用 lockfile 执行 conan install（无需也传递该 lockfile 中的包引用）。这现在成为了可能。Lockfile 始终包含执行 Conan install 所需的所有信息，唯一的障碍是更改“conan install”命令以接受不带包引用的 lockfile 将是破坏性更改。因此，我们没有在 Conan 1.x 中破坏 conan install，而是简单地向“conan lock”添加了一个子命令：conan lock install，它具有所需的支持。在 Conan 2.x 中，conan install 将直接支持 lockfile 作为输入，而 conan lock install 可能会被弃用。

用于 lockfile 捆绑包的 clean-modified 命令

在上一版本中，我们添加了对 lockfile 捆绑包 的支持，以便一次处理多个 lockfile。当时仅提供了最少的命令。在此版本中，我们添加了命令 conan lock bundle clean-modified，它与 conan lock clean-modified 执行的操作相同，但作用于捆绑包中的所有 lockfile。

使用 [conf] 控制构建并行化

作为一种一流的机制来配置 Conan 操作中特定且深度嵌套的行为，[conf] 功能开始按预期工作。从 Conan 1.35.0 开始，它可以用于控制传递给各种构建系统的 并行化参数，并具有非常灵活的语法。例如

[conf]
tools.build:processes=10
tools.microsoft.msbuild:max_cpu_count=20
some_package:tools.ninja:jobs=30
*:tools.ninja:jobs=30

配置文件部分中的四行演示了设置以下值：

  • 所有构建系统
  • 仅 MSBuild
  • 仅 Ninja，并且仅适用于名为 some_package 的包
  • 仅 Ninja，以及所有未命名为 some_package 的包。

这是一个 [conf] 的教科书式的预期用例的绝佳示例。

使用 [conf] 控制实际的 Visual Studio 安装

这里我们还有另一个 [conf] 的绝佳用法。请考虑以下配置文件

[settings]
compiler=msvc
compiler.version=19.0

[conf]
tools.microsoft.msbuild:vs_version=16

在这种情况下，vcvars 将定位并激活 Visual Studio 16 安装，但仍将使用 19.0 编译器版本，并且将设置相应的默认 toolset=v140。

从历史上看，在 Conan 中使用 Microsoft 工具时存在一些尴尬之处。Microsoft 发布它们的方式，在 IDE (Visual Studio)、编译器 (cl.exe) 和“工具集”（例如 toolset=v140）的版本之间存在隐式关联。“Visual Studio”编译器模型和更新的替代 msvc 编译器模型默认情况下“尊重”这些关联。在使用 msvc 编译器模型时，[conf] 的这种新用法为调用者提供了一种方法，可以精确控制构建中使用的 Visual Studio，但使用非默认版本的编译器和工具集。

MSBuildToolchain 生成 conanvcvars.bat

同样，本着许多其他新的和实验性功能的精神，MSBuildToolchain 已得到增强以提高可重复性和透明度。以前，工具链将在内部使用 Microsoft 的 vcvarsall.bat 来定位和使用所需版本的 Microsoft 构建工具并调用它，现在它会多执行一个步骤并将结果生成到 conanvcvars.bat 中，这使得位置在 Conan 进程之外也具有可重复性。如上一节所述，现在可以通过 [conf] 项 tools.microsoft.msbuild:vs_version 配置使用的 Visual Studio 版本，并且实际上该值将是 MSBuildToolchain 写入 conanvcvars.bat 的值。最后，还值得注意的是，MesonToolchain 实现 现在在后台使用此脚本（如果可用）来定位 Microsoft 构建工具。

遍历依赖关系图的新“访问者”模型

MSBuildDeps 生成器实现已重构为使用一种实验性的新功能来迭代整个依赖关系树以收集生成其文件所需的信息。新的 AutotoolsDeps 也正在使用此功能。这些是此功能的首次使用，并且发生在 Conanfile 的 generate() 方法中。此功能的其他潜在用例可能包括直接在配方的 validate() 方法中进行高级验证逻辑，但此类用例尚未经过测试。

以前，生成器会传递数据结构来进行操作

从理论上讲，这些数据结构为生成器提供了使用者所需的所有信息。这些数据结构旨在成为配方和生成器之间的分离层，以避免与可能发生变化的实现细节紧密耦合，并鼓励良好的边界。

但是，这些结构仅限于包含 Conan 团队认定使用者必需的某些信息。使用新的“访问者”模型，用户可以迭代依赖关系图中 conanfile 对象的实际实例。因此，生成器读取有关依赖关系的信息的所有限制都得到了有效消除。因此，例如，配方作者可以在 conanfile.py 中定义任意数量的自定义 Python 属性和方法，然后编写读取这些属性或执行这些方法的自定义生成器。此外，还提供了与每个实例关联的更多“隐式”信息，例如 package_id、依赖关系是 requires 还是 build_requires 等。简而言之，这使得生成器功能更加强大。

配方和配置文件的新环境模型

Conan 经常因其为管理围绕环境变量的复杂需求提供出色且优雅的一流体验而受到称赞。用户可以在 CLI 中传递变量，并且依赖关系图中的配方可以在 package_info() 方法中动态生成它们。变量被分为“构建”和“目标”上下文以用于交叉构建场景，并且虚拟环境生成器会生成设置相应变量的 shell 脚本。Conan 的“环境管理”正确处理的复杂案例数量始终很高，但从未达到 100%。始终存在一些似乎超出当前实现范围的案例。

然而，在对大量无法解决的 Github 问题进行广泛分析，并围绕 Conan 的环境建模进行讨论后，我们发现该模型存在一些缺陷。我们提出了一个改进的模型，我们相信它可以更接近地处理 100% 的用例。

与之前的环境管理相比，主要变化是可重复性。所有环境操作（变量添加/追加/删除）现在都在新的 Environment 类中显式实现。然后，在所有需要“应用”环境变量以进行各种 Conan 操作的地方，Conan 不再使用 Python 函数调用来应用它们，因为这些调用无法在 Conan 进程调用之外重现。相反，一个名为 VirtualEnv 的新生成器用于生成具有为给定上下文设置的适当环境变量的 shell 脚本。然后，Conan 将在它自己的 shell 调用中使用这些脚本以产生所需的结果，但用户可以从他们自己的 shell 中重现这种方式。因此，“协调环境”将始终在生成的可以打开、分析和重新用于在 Conan 之外重现构建操作的文件中可见。

新的 AutotoolsDeps，AutotoolsToolchain

延续之前关于新的（仍然**实验性**）生成器和工具链模型以及上面描述的新“环境”模型的工作，Conan 现在拥有 Deps 和 Toolchain 生成器类用于 Autotools。这些类会自动使用 VirtualEnv 生成器生成的 shell 脚本（如果可用）。


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

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