Conan 1.26 已经发布。毫无疑问，此版本中最重要的功能是引入了三种新的配方方法！第一个也是最重要的一个是 toolchain() 方法，所以让我们先谈谈这个。

新方法：toolchain()

toolchain() 方法的主要目标是将构建系统文件的生成与构建方法分离，以便这些构建系统文件可用于在 Conan 之外构建（无需运行 conan create 或 conan build）。一般来说，在 Conan 之外使用 Conan 依赖项信息出现在许多不同的上下文中。我们正在处理其中的一些，而此新方法旨在提供与本地开发流程相关的支持案例。

理论上，更改现有配方以使用新方法应该是透明且功能等效的。以下是此新功能的使用方法摘要

  • 在 conanfile.py 中定义一个新的 toolchain() 方法
  • 在该方法内部实例化 CMakeToolchain() 类
  • conan install 然后会生成一个 conan_toolchain.cmake 文件
  • 此步骤与 conanbuildinfo.cmake 的生成方式非常相似
  • 然后，在 Conan 之外运行 cmake 时，您可以使用以下命令：
    • cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
  • 使用 CMake() 辅助类时，此文件也将隐式使用

新方法：export() 和 export_sources()

此版本中添加的其他两种方法是 export() 和 export_sources()。这些方法的目标是提供更灵活的基于方法的替代方案，以替代众所周知的 exports 和 exports_sources 属性。它的工作原理是公开一个 self.copy() 函数，就像 source() 方法一样。

例如，您可以将以下代码更改为：

    exports_sources = "patches/**"

… 更改为 …

    def exports_sources(self):
        self.copy(pattern="patches/**")

透明的 CMake 集成

此版本发布的另一个重大公告是，我们朝着更透明的 CMake 集成又迈出了重要一步，方法是将组件支持添加到 cmake_find_package 生成器。通过此版本，用户现在可以在 CMake 项目中以真正透明的方式使用 Conan 依赖项。find_package 生成器提供了透明机制，而 组件 功能以及 Conan 中的可自定义目标名称功能使所有目标与开源社区的 CMakeLists.txt 中使用的现有目标名称、引用和相互依赖关系保持一致。这是超过一年计划的成果，因此这是一个非常令人兴奋的版本。

下图演示了项目和组件之间可能存在的每个细微依赖关系。在此图中

  • App1 直接依赖于完整目标 world/0.0.1
  • App2 直接依赖于 world/0.0.1 的 World::Worldall 组件
  • World::Worldall 组件直接依赖于 World::Helloworld 组件
  • World::Worldall 组件直接依赖于 Greetings::Bye 组件
  • World::Helloworld 组件直接依赖于 Greetings::Hello 组件
  • 没有任何内容直接依赖于 greetings/0.0.1 目标

CMake Components

值得注意的是，还有一个相关的 CMake 生成器称为 cmake_find_package_multi。此生成器尚不支持组件，但计划在将来的版本中支持。

新子命令：conan config init

过去，关于从头开始设置新的 conan 主目录时遇到的各种烦恼，有很多评论和建议。conan config install 处理了绝大多数用例，但并非所有用例。在许多利基情况下，用户希望使用当前 conan 版本中的所有默认值来配置新的工作区，这尤其尴尬。conan config init 提供了一种简单直观的方法来处理这些情况。

新生成器：MSBuild

我们从多个用户那里收到的反馈之一是，MSBuild 缺少类似于 CMake 中“目标”抽象的内容。当前 Visual Studio 生成器中生成的变量等效于 CMake 中的全局变量。因此，当将 conanbuildinfo.props 导入到 Visual Studio 项目中时，所有依赖项都将用于项目中的所有构建。这可能会因多种原因而造成问题。

新的 MSBuild 生成器 旨在提供比当前 Visual Studio 生成器更多的优势。首先，生成器的名称与构建系统的名称匹配，这仅仅是改进一致性。更重要的是，它在生成 .props 文件中生成依赖项信息的方式中使用了完全不同的结构。这使得用户能够在每个项目的基础上选择性地导入依赖项。由于我们希望此生成器成为 MSBuild 项目的新标准，因此我们非常重视用户的反馈。如果您有机会试用它，请与我们联系并告诉我们您的想法。

其他功能和修复

对于配方作者，我们还有一些额外的功能。我们有一个新的 “remove_files_by_mask” 工具用于清理。我们有一个新的 stdcpp_library 工具，用于评估当前构建的 C++ 标准，并更容易在其周围编写条件语句。在相关说明中，我们还在两个方面进一步改进了对 Intel 编译器的支持。我们现在自动处理 C++ 标准标志，并使 CMake 辅助调用 compilervars.sh，这是与 Intel C++ 编译器正确互操作所必需的。

像往常一样，我们无法在本博文中介绍此版本中的所有内容，因此请访问 更改日志 以获取完整列表。


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