又一个月过去了，Conan 又发布了一个新版本。这次我们带来了 1.15 版本，其中包含一些有趣的更改，并暗示了接下来会发生什么。

新的设置 compiler.cppstd 用于处理 C++ 标准

Conan 内部模型也负责处理 C++ 标准，在此版本之前，可以在配方中定义设置 cppstd，并使用它根据其值生成不同的包。在此版本中，我们为了向后兼容性保留了此行为，但已决定将其移至 compiler 下的子集中。

此更改背后的主要动机有两个：作为每个编译器的子集，可以更细粒度地控制此设置对不同编译器可以取的值（例如：现代 Visual Studio 没有 C++11 的标志，GNU 编译器可以使用 gnu++17 或 c++17 来激活或不激活扩展）；另一个主要动机是，这将允许现有的配方受益于此子集（构建帮助程序和生成器将考虑它），而无需修改配方以显式添加 cppstd 设置。

即使 cppstd 设置现在已弃用，但它仍将在所有 1.x 版本中以相同的方式工作，但是，我们鼓励用户使用新设置并将现有配方迁移以采用此新行为（Conan 会相应地发出警告）。此外，设置 compiler.cppstd 的用法与已弃用的 cppstd 不兼容，不能同时使用两者。

要使用 compiler.cppstd，您只需要在您的 settings.yml 文件中提供此子集（Conan 提供的默认值已包含当前值），并且您应该在您的配置文件或使用命令行提供一个值。

配置文件

[settings]
os=Windows
arch=x86_64
compiler=Visual Studio
compiler.version=15
compiler.cppstd=17
build_type=Release

Conan 的构建帮助程序在调用编译器时会考虑此值，Conan 将为每个不同的值生成不同的包 ID。如果未提供值，则将使用给定编译器版本的默认值，并且默认情况下，Conan 将生成与显式设置该默认值时相同的包 ID（此包 ID 也将与使用已弃用的 cppstd 设置生成的包 ID 相同）。

您可以在文档的此部分中找到更多信息，还可以查看新的settings.yml 文件。

部署生成器

用户经常要求如何将工件从 Conan 缓存提取到用户空间。关于 deploy() 方法以及每个包都需要具有默认部署行为的必要性，已经进行了长时间的讨论。尽管我们尚未放弃这一点，但我们希望探索另一种方法。

目前，配方是描述如何部署包的，这是有道理的：包知道其部署所需的工件及其依赖项所需的资源。但是，在某些情况下，您可能希望将部署逻辑与配方分离，并能够以相同的方式部署每个包。

遵循此原理，我们认为这种观点更接近于使用者方面，并让他们选择如何完成部署。感谢用户的反馈并对一些想法进行了验证，我们提出了**部署生成器**的想法：具有部署逻辑的自定义生成器包，可用于使用/部署任何现有包。

该deploy生成器只是一个 Conan 内置生成器，它将依赖关系图中每个包的包文件夹的内容复制到安装文件夹。

例如

$ conan install paho-cpp/1.0.1@conan/stable -g deploy -if deployment
...
paho-c/1.3.0@conan/stable: Package installed 77ff8c6f250452f5f8a074c1c5192b5d1e08ca01
paho-c/1.3.0@conan/stable: Downloaded package revision 0
paho-cpp/1.0.1@conan/stable: Retrieving package 4afa3667876e410c5723826d8099526aa8c90bb1 from remote 'conan-center'
...
paho-cpp/1.0.1@conan/stable: Package installed 4afa3667876e410c5723826d8099526aa8c90bb1
paho-cpp/1.0.1@conan/stable: Downloaded package revision 0
Generator deploy created deploy_manifest.txt
Generator txt created conanbuildinfo.txt

然后，在安装文件夹中，您将找到包的内容。

$ ls deployment
paho-cpp/  paho-c/  deploy_manifest.txt  conanbuildinfo.txt

如果您想自定义部署布局，您可以创建一个自定义脚本，将文件从此基本布局复制到您的自定义布局，或者您可以创建自己的生成器。

通过 Python 重用源文件需要

在 Conan 1.9 版本中，我们引入了 Python 依赖项作为一种从现有配方重用 Python 代码的方式，而在此版本中，我们正在定义如何重用源文件。我们通过python_requires属性添加了一种显式执行此操作的方法。可以使用类似 self.python_requires["pyreq"].exports_sources_folder 的内容来重用 Python 依赖项导出的源代码。

此外，如果您想重用源代码并从基本 ConanFile 继承，我们建议您对 Python 依赖项配方遵循此方法。

带有 Python 依赖项和重用 CMakeLists.txt 的基本 ConanFile 的 conanfile.py

import os
import shutil
from conans import ConanFile


class PythonRequires(ConanFile):
    name = "pyreq"
    version = "version"

    exports_sources = "CMakeLists.txt"


def get_conanfile():

    class BaseConanFile(ConanFile):

        settings = "os", "compiler", "build_type", "arch"
        options = {"shared": [True, False]}
        default_options = {"shared": False}
        generators = "cmake"
        exports_sources = "src/*"

        def source(self):
            # Copy the CMakeLists.txt file exported with the python requires
            pyreq = self.python_requires["pyreq"]
            shutil.copy(src=os.path.join(pyreq.exports_sources_folder, "CMakeLists.txt"),
                        dst=self.source_folder)

    return BaseConanFile

请注意函数 get_conanfile()，它可以用作避免重复声明 ConanFile 对象并使 Python 依赖项的逻辑保持分离的一种方式。

您可以在文档中找到扩展示例和更多相关信息：Python 依赖项：重用代码

正在进行的开发和未来工作

随着我们继续开发 Conan，我们已就一些重要功能达成一致，这些功能可能会对工具的演变和用户体验的改进产生重大影响。过去，我们已与其他大型功能并行开发，例如版本或工作区。从下一个版本开始，我们将开始更多地关注相关功能。

以下是我们希望在不久的将来推出的功能简要列表

  • 图形锁定：创建一种考虑图形关系来锁定依赖项的方法，并能够使用收集的信息重现构建（https://github.com/conan-io/conan/pull/5035）。
  • 交叉构建：专注于“上下文构建”概念的交叉构建模型的新方法（https://github.com/conan-io/conan/projects/4）。
  • 组件：如何在同一个包内建模库的内部关系（https://github.com/conan-io/conan/issues/5090）。
  • 构建帮助程序和生成器：将构建逻辑与生成器中的依赖项信息分离，并能够为构建系统提供构建帮助程序使用的所有信息（https://github.com/conan-io/conan/projects/5）。

这意味着我们将专注于 Conan 的关键功能的开发工作，尽管我们不会停止每月的发布计划。每个版本都会发布包含错误修复和改进的版本，我们将以更稳定的方式引入这些大型功能。

我们相信这是向社区提供有意义的功能的正确途径，这将有助于塑造 Conan 2.0 的更好工具的未来。


不要忘记在更改日志中查看完整的功能和修复列表，并更新。

最后，如有任何错误报告或反馈意见，请随时提交新的问题进行讨论。非常感谢！