我们很高兴地宣布 Conan 1.49 发布，它包含了一些重要的新功能和错误修复。首先，值得一提的是，我们终于移除了对 Python 2 的支持。此外，我们对 CMakePresets 支持进行了一些改进，允许使用配方设置和选项的值来参数化输出文件夹。现在，您可以使用 conanfile.txt 中的布局功能，添加 [layout] 部分。引入了一个新的 tools.apple.fix_apple_shared_install_name 工具，用于修复未设置正确 LC_ID_DYLIB 和 LC_LOAD_DYLIB 字段的共享库。最后，我们添加了两个新的辅助函数：conan.tools.build.can_run() 和 conan.tools.microsoft.check_min_vs()。

移除 Python 2 支持

从 1.49 版本开始，Conan 将不再支持 Python 2。这是因为 Conan 依赖项的安全漏洞 在 Python 2 中没有得到解决，因此向前迈进的唯一选择是最终移除 Python 2 支持。

Python 2 在两年前半正式宣布终止支持，并且 Conan 1.22 已经声明 Python 2 不受支持。在之前的 Conan 版本中添加了额外的阻止程序，以提醒所有人。由于安全漏洞超出了我们的范围，因此无法继续支持 Python 2。

请升级到 Python>=3.6 以继续使用 Conan>=1.49。

conanfile.txt 中新增 [layout] 部分

在 Conan 1.49 之前，您只能通过在 conanfile.py 中定义方法来使用布局 功能。Conan 1.49 也支持在 conanfile.txt 中使用布局。您现在可以在您的 conanfile 中添加一个新的 [layout] 部分，以添加以下预定义布局之一

对于 cmake_layout，此功能使使用 conanfile.txt 的使用者能够利用 CMakePresets 集成。让我们来看一个简单的使用者项目示例，该项目构建一个具有以下结构的 compressor 应用程序

├── CMakeLists.txt
├── conanfile.txt
└── src
    └── compressor.c

其中 conanfile.txt 声明了 cmake_layout，需要 zlib/1.2.11 并使用 CMakeDeps 和 CMakeToolchain 生成器

[requires]
zlib/1.2.12

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

如果您执行 conan install .，您会看到文件是根据默认的 cmake_layout 生成的，并且 CMakeUserPresets.json 会创建在基础文件夹中，与 CMakeLists.txt 相邻。

├── CMakeLists.txt
├── CMakeUserPresets.json
├── build
│   └── generators
│       ├── CMakePresets.json
│       ├── FindZLIB.cmake
│       ├── ...
│       └── module-ZLIBTargets.cmake
├── conanfile.txt
└── src
    └── compressor.c

然后，您可以调用 CMake 来调用预设

cmake --preset release
cmake --build --preset release

构建结果将与我们在 conanfile.py 中使用在 layout() 方法中定义的 cmake_layout 时相同。

.
├── CMakeLists.txt
├── CMakeUserPresets.json
├── build
│   ├── Release
│   │   ├── CMakeCache.txt
│   │   ├── CMakeFiles
│   │   │   └── ...
│   │   ├── Makefile
│   │   ├── cmake_install.cmake
│   │   └── compressor
│   └── generators
│       ├── CMakePresets.json
│       ├── ...
│       └── module-ZLIBTargets.cmake
├── conanfile.txt
└── src
    └── compressor.c

您可以检查 compressor 应用程序是否已在 /build/Release 文件夹中构建，如 cmake_layout 中所定义。

使用参数化布局改进 CMakePresets

Conan 在最近的版本中逐步改进了对 CMakePresets 的支持。从 Conan 1.49 开始，您可以使用新的 tools.cmake.cmake_layout:build_folder_vars 配置来修改 cmake_layout 的默认值，以用于 conanfile.folders.build 和 conanfile.folders.generators 属性，以及 CMakePresets 的默认预设名称。让我们从之前的 [layout] 示例开始，了解它是如何工作的。

如您所知，预设和输出文件夹的名称默认为 build_type 设置的值，因此默认情况下命名为 Release 或 Debug。让我们使用此配置更改该默认值，以便这些文件夹和预设名称考虑其他设置，例如 arch 设置。

让我们执行 conan install 并将 tools.cmake.cmake_layout:build_folder_vars 配置作为参数传递

conan install . -c tools.cmake.cmake_layout:build_folder_vars='["settings.arch"]'

现在，如果您列出可用的预设，您将看到一个新的预设，其中包含体系结构，并且构建将输出文件到相应文件夹，文件夹名称中包含使用的体系结构和构建类型。

$ cmake --list-presets
Available configure presets:

  "Release"        - 'Release' config
  "Release-x86_64" - 'Release-x86_64' config

$ cmake --preset Release-x86_64
...

$ cmake --build --preset Release-x86_64
...

新增 tools.apple.fix_apple_shared_install_name 工具

我们添加了一个新的工具 tools.apple.fix_apple_shared_install_name，以帮助用户解决 Apple 平台上共享库可能出现的问题。

正如我们在 Conan 文档 中解释的那样，在 Apple 平台上使共享库可重定位需要额外的努力，因为在构建共享库时，两个名为 LC_ID_DYLIB 和 LC_LOAD_DYLIB 的字段（包含“安装名称”）会被嵌入到库头信息中，通常指向文件系统中的绝对共享库位置。此绝对位置将导致库在不同的系统中加载失败，因为该系统中没有该位置的库。

避免此问题的最佳解决方案是为链接器传递适当的标志，以便将绝对文件夹替换为 @rpath 值。@rpath 特殊关键字将告诉加载程序搜索路径列表以查找库。这些路径可以通过库的使用者通过链接器选项定义 LC_RPATH 字段来定义。值得注意的是，例如，CMake 将默认执行此操作，搜索您正在链接的库并添加指向这些库的 LC_RPATH 条目。

并非所有库都准备提供可重定位的共享库，因此，如果您为一个二进制文件不可重定位的库创建包，则只有两个选择：要么修补库的构建脚本以使其可重定位，要么在构建后修复二进制文件。

tools.apple.fix_apple_shared_install_name 工具可以在构建步骤之后帮助修复二进制文件。您通常会在配方的 package() 方法中调用此工具，在将二进制文件移动到包文件夹之后。让我们看看如何使用一个使用 Autotools 作为构建系统的库示例来使用它

from conan.tools.apple import fix_apple_shared_install_name

class HelloConan(ConanFile):

  ...

  def package(self):
      autotools = Autotools(self)
      autotools.install()
      fix_apple_shared_install_name(self)

此工具将搜索包文件夹中的所有共享库，并修复 LC_ID_DYLIB 和 LC_LOAD_DYLIB 的值，以便它们使用 @rpath 关键字而不是绝对文件夹来指向库。这样，您就可以在具有不同位置的不同系统中安装此包，并确保库将加载。

有关此工具工作原理的更详细说明，请阅读 Conan 文档。

新增 can_run() 和 check_min_vs 辅助函数

最后，还有两个新的工具值得一提

  • conan.tools.build.can_run(conanfile)：这在测试包中可能是一个有用的工具，而不是使用 cross_building() 工具检查二进制文件是否已交叉编译，您可以使用 can_run() 来涵盖主机平台可以运行为其他体系结构构建的二进制文件的情况。对于 Mac M1 机器来说就是这样，它可以运行 armv8 和 x86_64 可执行文件。

  • conan.tools.microsoft.check_min_vs(conanfile,version)：此工具检查我们是否至少使用了 msvc 或 Visual Studio 编译器的最低要求版本。重要的是，它将接受 Visual Studio (1.x) 和 msvc (2.0) 编译器的版本参数，允许在不破坏的情况下将配方从 1.X 迁移到 2.0。


除了上面列出的内容之外，还有一些小的错误修复，您可能希望了解。如果是这样，请参考 变更日志 以获取完整列表。

希望您喜欢此版本，并期待您的 反馈。