我们很高兴地宣布 Conan 1.43 已发布，并带来了一些重要的新功能和错误修复。我们正在努力提供工具来帮助用户为 Conan 2.0 准备他们的 recipes。例如，我们更改了 cpp_info 属性模型，以推动 Conan Center 中 recipes 的迁移，降低了破坏使用当前 cmake_find_package/multi 生成器的用户的风险。此外，为了帮助准备 2.0 的 recipes，我们添加了一个新的 test_requires() 方法，以帮助迁移 build_requires() 方法中的 force_host_context 参数。你还可以从 conan 命名空间（2.0 中唯一存在的命名空间）导入 recipes 中的 ConanFile，而不是 conans 命名空间。除此之外，还有一个新的 tools.gnu.PkgConfig，它取代了 tools.PkgConfig。最后，我们有一个新的 os 设置来表示没有操作系统的硬件平台。

为 Conan 2.0 准备你的 recipes

Conan 2.0-alpha2 于上个月发布。我们有一个 新的文档章节 来帮助用户准备他们 1.X 中的 recipes 以与 Conan 2.0 语法兼容。如果你想尝试 Conan 2.0，可以使用 pip 安装它

$ pip install conan==2.0.0-alpha2

cpp_info 属性模型中的更改

从 Conan 1.43 开始，我们决定属性模型仅由新的生成器（如 CMakeDeps 和 PkgConfigDeps）使用。当前的生成器，如 cmake_find_package 和 cmake_find_package_multi，将不会监听这些属性。使 cpp_info 信息独立设置使迁移过程不太容易出错。缺点是我们需要同时维护旧的 .names、.filenames 等属性和在 Conan Center Index 中 recipes 中共存的 set_property 方法。一旦我们不再支持当前生成器（Conan 2.0 发布后的某个时间），这种共存关系将结束。然后，旧属性将从 recipes 中消失，并且只有 set_property 模型将保留。

在 recipes 中引入新的属性模型时，必须考虑几个细节。

  • 与 .names 属性相反，使用 cmake_target_name 属性设置的目标名称是“绝对的”。这意味着 Conan 不会在使用此属性设置的值之前添加任何命名空间。
  • 当用户使用 CMakeDeps 生成器时，此生成器默认会创建 config CMake 脚本。要生成 CMake 模块文件，必须为该生成器设置 cmake_find_mode 属性。

让我们看看 recipes 如何修改以及在从 Conan 1.X 到 2.0 的此转换过程中它们将如何显示。

...
class AlembicConan(ConanFile):
    name = "alembic"
    ...
    def package_info(self):
        self.cpp_info.names["cmake_find_package"] = "Alembic"
        self.cpp_info.names["cmake_find_package_multi"] = "Alembic"
        ...

在当前模型中，cmake_find_package/multi 生成器将创建 Alembic::Alembic 目标。对于文件名，它将继承使用 .names 设置的值并生成 FindAlembic.cmake、AlembicConfig.cmake 等。要为新的 CMakeDeps 生成器设置相同的信息，我们应该添加 cmake_target_name 和 cmake_file_name 属性。

...
class AlembicConan(ConanFile):
    name = "alembic"
    ...
    def package_info(self):
        self.cpp_info.names["cmake_find_package"] = "Alembic"
        self.cpp_info.names["cmake_find_package_multi"] = "Alembic"
        self.cpp_info.set_property("cmake_target_name", "Alembic::Alembic")
        self.cpp_info.set_property("cmake_file_name", "Alembic")
        ...

请 查看文档，了解有关如何在你的 recipes 中设置属性以准备 Conan 2.0 的详细指南。

使用 test_requires 代替 force_host_context

我们已向 recipes 中添加了一个 self.test_requires() 方法，旨在替代 self.build_requires() 方法中的 force_host_context 参数。这是在 host_context 中为 Conan 2.0 设置构建需求的方式。请将你的 recipes 更新为新的语法。

from conan import ConanFile

class App(ConanFile):
    name = "app"
    version = "1.0"
    def build_requirements(self):
        self.test_requires("gtest/1.11.0")

请注意上面 recipe 中的**另一个语法更改**。现在你可以执行 import ConanFile from conan import ConanFile 导入，而不是旧的 from conans ...（注意复数）。

新的 tools.gnu.PkgConfig

Conan 1.43 带来了新的 tools.gnu.PkgConfig 工具，该工具改进了并取代了当前的 tools.PkgConfig 工具。此工具可以从现有的 .pc 文件中提取信息。这可以用于，例如，在某些系统安装的库上创建“系统”包 recipe，作为一种自动从系统提取 .pc 信息的方法。或者，如果某些专有包具有仅输出 .pc 文件的构建系统。

此工具提供了一个 fill_cpp_info() 方法，该方法可以在 package_info 方法中使用，以将 .pc 文件中的信息转换为 Conan cpp_info。让我们看一个例子。

...
class MyPkg(ConanFile):
    ...
    def package_info(self):
        pkg_config = PkgConfig(self, "gl")
        pkg_config.fill_cpp_info(self.cpp_info, is_system=True)
        ...

这将从 gl.pc 文件中获取信息，并将其转换为 cpp_info 的属性。例如，在这种情况下，它会将 GL 添加到 self.cpp_info.system_libs 中。请查看 Conan 文档，了解有关新的 PkgConfig 工具的更多详细信息。

用于没有操作系统的硬件平台的新 baremetal os 设置

Conan 1.43 带来了一个新的 baremetal os 设置，该设置已添加到默认的 Conan 设置中。此设置只是一个通用的名称约定，预计用户可能会使用进一步的子设置自定义 baremetal 设置中的空间，以指定其特定的硬件平台、板卡、系列等。

os=baremetal 值尚未被 Conan 内置工具链和帮助程序使用，但预计随着其发展，它们将来会开始使用它。


除了上面列出的项目外，还有一些较小的错误修复，你可能希望了解。如果是这样，请参阅 更改日志 以获取完整列表。

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