Conan 2.0 新的速查表终于来了！

这是了解 Conan 2.0 激动人心新功能的最简单方法

比较 1.x 和 2.0

最大的变化之一是命令行，并且可以通过视觉效果来体现

明显的改变，新的设计以及第一列和第二列交换了位置，但这并不重要，我们将根据开头部分的标题来引用它们。

让我们深入了解这些变化。

搜索包

需要仔细观察才能注意到这两者之间唯一的区别。如果你发现了/*，那就是统一引用的证据。这允许在指定名称、版本、用户或通道时具有更高的粒度。此更改也应用于配方以访问依赖项。有关更多详细信息，请参阅配置文件模式。

使用包

这很可能是你遇到变化的地方。

Conan install

如果--requires 吸引了你的注意，那太好了。注意@不见了？这是 1.x 和 2.0 之间的变化。Conan 区分传递 CLI 引用还是路径的方式更加明确。
引用丢失了@后缀，并通过专用的参数--requires明确调用。这适用于所有命令，而不仅仅是install命令。这应该可以缓解引用与 Conanfile 路径名称相同的意外情况，从而导致用户输入错误。

注意：添加用户和/或通道时，仍然需要@，如果没有用户，则可以省略@。

接下来是conan install <path>，例如./conanfile.py（如果它在你的当前目录中），这没有改变。还有其他需要考虑的事项，例如布局，如果你之前使用过--install-folder，则可能需要在配方中进行调整。

Conanfile.txt 和构建系统

这里我们将看到最多的变化，有两个主要的变化

• 我们正在使用不同的生成器
• 现在有一个布局部分

[requires]
zlib/1.2.13

[generators]
cmake_find_package

[requires]
zlib/1.2.13

[generators]
CMakeToolchain
CMakeDeps

[layout]
cmake_layout

注意：示例更侧重于 CMake，而不是在 Conan 1.x 列中列出不同的生成器

这利用了 Conan 1.33 中添加的功能。我们使用了新的生成器 CMakeToolchain 和 CMakeDeps，最后利用了布局。

提示：这完全是有效的 Conan 1.x 语法，如果你正在使用它，那么切换到 2.0 会比较困难。请确保在迁移计划中使用最新的 Conan 1.x 功能！

布局与更新的生成器一样重要。它的作用是告诉 Conan 我们的代码和构建脚本位于何处。对于此示例，关键作用是指定生成文件的输出位置。如果没有此项，Conan 将把所有内容输出到当前目录。

考虑到这一点，如果我们查看 1.x 示例中的下一个命令，我们过去会执行mkdir build && cd build。由于我们在 2.0 conanfile.txt 中声明了cmake_layout，因此我们不再需要这样做。

所有这些都产生了连锁反应。现在我们不再需要更改目录（构建文件夹在 Conanfile 的声明中是明确的），安装命令也略有更改，路径从父目录变为当前目录。少打一个字符。

注意：示例更侧重于 CMake，而不是在 Conan 1.x 列中列出不同的生成器

如果你还没有听说或尝试过CMake 预设，那么你就错过了。这使得设置项目变得更加容易。此示例需要 CMake 3.23 或更高版本，但这不是必需的，因为你可以明确地将 CMake 3.15 或更高版本的工具链文件传递给 CMake：-DCMAKE_TOOLCHAIN_FILE=build/generators/conan_toolchain.cmake。（确切的路径取决于 CMake 生成器、平台和设置，因此请阅读 CLI 输出，它将提供正确的路径）。

客户端配置

这将包括“显示本地客户端配置”和“配置本地客户端”，以及“添加或修改客户端配置”。我们还将比较“远程存储库配置”。

这些部分混合得最多，因为

• conan config 更加简洁
• conan user 已移至conan remote login

为了使比较更容易，我重新组织了命令（来自旧的 1.x 端），使其与新的替换项一一对应（或没有对应项）

首先，我们有一个在 2.0 速查表中突出显示的命令，但最初在 1.x 中不存在。这是最常被请求的功能之一，即选择加入默认配置文件。管理配置文件 是在 CI/CD 中使用 Conan 进行 DevOps 的关键决策之一。我们见证了围绕依赖于conan profile detect 的不良习惯，这限制了改进客户端的能力。在 Conan 2.0 中，检测到的配置没有保证稳定性，如果你之前使用过conan config set，则需要重新考虑这一点，因为出于同样的原因，该命令也被删除了。替代方案是自定义命令或托管配置文件。

conan config list，这是一个非常简单的命令，它显示所有可能更改的可用配置。要显示值，conan config get 已被conan config show 替换，后者采用与值相同的模式。例如tools.build.cmake.* 用于列出global.conf 中当前定义的所有特定于 CMake 配置的值。

conan config install 没有改变，并且是管理配置文件的推荐方法，在 1.x 中使用设置，在 2.0 中使用自定义命令或扩展。

conan profile show default 获得了与conan install 相同的-pr，体现了统一命令行语法的优势。conan profile show 也在 2.0 中有效，这应该是在终端中输入按键时的简化操作。

一些简单的命令供审查

• conan remote list – 未更改
• conan remote add – 未更改
• conan user 已被conan remote login 替换。

显示信息

conan inspect 基本上没有改变，它仍然专注于本地配方。对于迁移，它删除了-a attribute，这被结构化输出所取代。你可以添加-f json 以获得更易于机器读取的格式进行处理。

conan get 已被删除 – 单独的配方或访问远程托管的导出/包的部分容易出错且被误用 – 相反，你可以使用conan cache path 获取文件夹，然后根据需要打印文件内容。

conan info 已合并到conan graph 中作为子命令，因为它们紧密耦合。它获得了与install 相同的统一引用语法，因此这里有--requires。最后一个命令具有--format html，这是新的格式化程序语法。这支持 Conan 1.x 中存在的 HTML 视图。

创建包

最后但并非最不重要。

New 命令的语法和更新模板都进行了更新。此更改的目的是为了能够传递更多不同的输入，例如，某些模板可以在创建时添加需求，在此示例中添加 -d requires=pkg/0.1 即可实现。

Export 命令不再作为特性提供，但仍然是一个具有相同功能的有用命令。

Create 命令保持不变，但实现了新的引用语法并删除了已弃用的标志。

在此示例中，Conan create 命令保持不变，但是“填充引用”的方式发生了变化，名称、版本、用户、通道现在使用同名参数传递，而不是已移除的 1.x 引用语法。conan create . 1.0.0@frog 现在变为 conan create . –version 1.0.0 –user frog。

上传包

这里有一些细微的变化，之前示例中使用的引用匹配任何以 zlib 开头的配方，包括 zlib-ng，这不是预期的结果，因此现在使用统一的引用语法，它只显式匹配版本，因为存在 /。
我们的示例远程名称已更改，只是样式上的调整，不影响功能。

最后，--all 选项已不再存在，在 2.0 版本中，它现在是默认行为，并且现在可以使用 --only-recipe 来实现旧的选项行为。

在缓存外部部署

这段代码片段中包含 2 个新特性。

• 部署器
• 无缓存工作流（更多信息请参阅 上周的博客）

之前，旧的部署生成器 只将所有文件复制到本地目录，本质上是解压位于远程的 conan_package.tgz 文件。这有一些缺点，并且有大量请求需要更专业的版本。它被 部署器 替换。新的 内置 full_deploy 替换了旧的部署生成器，并具有相同的功能。它获得了对其他生成器的支持，这些生成器可以与部署器结合使用，这样 CMakeDeps 将创建使用“完整部署”内部路径的文件（即不引用缓存！）。这是一个长期以来一直被请求的工作流，现在在 2.0 版本中成为可能。