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

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

这利用了 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 的声明中明确指定），安装命令略有变化，路径从父目录更改为当前目录。少打一个字符。

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

如果你还没有听说过或尝试过 CMake 预设，那么你错过了很多。这使得设置项目变得更加容易。此示例需要 CMake 3.23 或更高版本，但这不是必需的，因为你可以显式地将工具链文件 -DCMAKE_TOOLCHAIN_FILE=build/generators/conan_toolchain.cmake 传递给 CMake 3.15 或更早版本。（确切路径会因 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 参数用于实现旧的行为。

在缓存之外部署

此代码片段包含两个新功能。

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

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