Conan 1.24 带来了大量已完成的功能请求，包括主要功能和次要功能。最大的变化与跨构建模型有关，并在处理用户今天正在处理的一些最复杂的包时提供了更多功能。这包括Protobuf和LLVM（仅举几例）。还有一些细微的补充，这些补充是朝着一些长期目标迈出的渐进步骤，例如支持像CMake这样的构建系统中的“组件”，为cppstd提供强大的抽象，帮助用户通过更多选择性弃用为 Conan V2.0 做好准备。

跨构建建模 + 上下文建模

在2017年，我们实现了对 Conan 的跨构建支持，这主要基于在构建系统中跨构建模型的经验。我们使用新的os_build/arch_build和os_target/arch_target设置更新了os和arch的设置模型。该模型在内部和用户中得到了广泛使用，这导致了来自各种用例的宝贵反馈。根据这些反馈，很明显该模型是不够的，需要更强大的东西。

该新模型添加了一个新的命令行参数，用于指定一个完全独立的配置文件，该配置文件将用于构建依赖关系图中的build_requires。这听起来很简单，但它是通过提供一个名为“上下文”的新抽象来实现的。在一个上下文中构建build_requirements（称为“构建上下文”），在另一个上下文中构建其余的requirements（称为“主机上下文”）。需要注意的是，在必要时，也可以强制构建需求保留在主机上下文中，如果它们在配方中声明。下图显示了如何使用“上下文”来允许像“protobuf”这样的build_requirement使用一个配置文件的“zlib”，而包“my_pkg”使用另一个配置文件的zlib。

context example diagram

在conanfile.py中新增init()方法

从根本上说，conanfile.py是一个 Python 类。它的所有现有函数都经过精心设计，以模拟构建和打包 C/C++ 的问题。但是，在大规模情况下，需要在配方之间管理和共享代码（例如为 Conanfiles 提供一个基类），并且创建了python_requires来实现这一点。

根据用户的反馈，围绕 Conanfile Python 对象的基本实例化仍然存在一些有价值的功能，但目前尚不可行。如果定义了新的init()方法，它现在将成为第一个运行的 conanfile 函数（它在 config_options 之前运行）。

注意：init()方法旨在与python_requires()一起使用。其他用途可能会导致不良后果。

新的 Markdown 生成器

添加了一个新颖的新生成器，它从包中生成一个 markdown (.md) 文件，该文件根据 Conan 包提供包信息的摘要。这适用于流行的 Web 前端呈现给git存储库（如 Github/Gitlab/Bitbucket），这些存储库中README.md的特殊呈现很常见。

markdown generator sample

面向未来生成器的组件 API

许多流行的库使用 CMake 作为构建系统，并利用 CMake 的一个名为“目标组件”的功能。这允许使用者编译和链接库的某些部分，同时忽略其他部分。这种粒度为尝试与 CMake 集成的工具增加了很大的复杂性，但它被流行库的使用者广泛使用，因此它一直是我们想要支持的内容。在此版本中，我们添加了一些功能，使我们更接近该目标。此外，可以想象其他构建系统可能具有类似的概念，因此我们尝试以通用的方式实现这些功能。

对于此版本，我们在cpp_info中添加了一个名为“components”的新成员。它是一个字典，其中键是组件名称，值是每个独立的cpp_info实例。因此，每个组件都可以使用与单独的包相同的信息进行宣传（在cpp_info方面）。如果您熟悉 CMake 组件和 Conan 生成器的工作原理，那么应该很容易想象现有的 CMake 生成器如何将这些 Conan 组件转换为 CMake 组件。

需要指出的是，此新成员尚未实现到任何生成器中。事实上，components成员已有意从deps_cpp_info中省略，因此无法使用。如前所述，这只是最终支持组件概念的第一步。请继续关注下一个版本以获取更多进展。

CONAN_V2_MODE 弃用

在 Conan v1.x 中，添加了一些机制来增强配方作者在许多配方之间共享代码的能力。在野外使用一段时间后，很明显其中一些机制存在安全或可支持性问题。在此版本中，启用CONAN_V2_MODE将禁用其中两种机制

  • <cache>/python将不再添加到sys.path中
  • env_info中的PYTHONPATH将不再为python_requires包追加

SystemPackageTool 行为更改

SystemPackageTool的默认全局行为始终是自动运行系统包管理器命令来获取或更新系统依赖项。用户可以通过将环境变量CONAN_SYSREQUIRES_MODE设置为其他两种模式之一来覆盖此全局行为：disabled或verify。

默认值和环境变量本质上都是“全局的”（影响所有配方）。根据用户的请求，我们现在添加了一种影响此行为的新方法：“每个包”。每个conanfile.py现在可以指定它自己的默认行为，即SystemPackageTool构造函数的default_mode参数。

因此，控制此行为的“新”优先级如下

  1. 全局：CONAN_SYSREQUIRES_MODE环境变量（如果已定义）
  2. 每个包：default_mode参数（如果已定义）
  3. 全局：enabled程序默认值

注意：参数名为default_mode，因为它仅在CONAN_SYSREQUIRES_MODE环境变量未设置时适用。如果环境变量设置为任何值，则每个配方中的default_mode参数将完全被忽略。

其他功能和修复

此版本实际上包含了太多激动人心的功能和错误修复，我们无法一一列举。与往常一样，您可以在更改日志中查看完整列表。但是，以下是一些值得一提的功能

  • 添加tools.cppstd_flag()以检索当前设置的实际编译器标志
  • 对Cygwin的短路径支持
  • 缺少二进制文件时提供更详细的信息
  • 支持tools.get()中的镜像
  • 在conan info的输出中添加描述字段
  • 避免不必要的 CMake find_package()调用
  • 多个 Sun C 编译器的修复


像往常一样，我们希望您喜欢此版本，并期待您的反馈。