Conan 2.0 为开发者实现了与 Conan 无关的依赖项部署

我们知道，升级到 2.0 这样的主要版本可能需要一些努力，我们自己也投入了大量资源来持续升级 ConanCenter 中央仓库中的包。但是 Conan 2.0 的新架构和设计将允许在其之上更好地更快地进行迭代，这是 Conan 2.0 的许多新增功能中的第一个。

这项新功能允许将 Conan 依赖项工件直接安装到您的项目文件夹中，并实现完全与 Conan 无关的项目，即使在系统中未安装 Conan，也可以构建和运行该项目。对于某些情况下，正常 Conan 开发流程不可行，这始终是一个被强烈要求的功能。

Conan 包的正常安装和使用

下图说明了使用 Conan 安装和使用依赖项的正常流程

当 Conan 安装依赖项时，它们被安装到“Conan 缓存”中，默认情况下，该文件夹位于用户主目录（Conan 不需要在系统级别安装任何内容），因此所有使用这些依赖项的项目都可以轻松使用它们。

Conan 生成的文件，例如 conan_toolchain.cmake 或用于在 Conan 缓存中正确定位依赖项的 xxx-config.cmake CMake 文件，将包含指向 Conan 缓存中头文件、库和二进制文件位置的绝对路径。

开发流程通常是 conan install . 来安装依赖项，然后使用生成的预设或生成的工具链调用 cmake 来构建项目。

创建与 Conan 无关的依赖项部署

使用 Conan 2.0 的新 full_deploy 部署器，可以创建与 Conan 无关的依赖项副本，即使在计算机中未安装 Conan，开发人员也可以使用该副本。

让我们来看一个例子。所有源代码都在 examples2.0 Github 仓库中。

  $ git clone https://github.com/conan-io/examples2.git
  $ cd examples2/examples/extensions/deployers/development_deploy

在该文件夹中，我们可以找到以下 conanfile.txt

  [requires]
  zlib/1.2.13

  [tool_requires]
  cmake/3.25.3

  [generators]
  CMakeDeps
  CMakeToolchain

  [layout]
  cmake_layout

该文件夹还包含一个标准的 CMakeLists.txt 和一个 main.cpp 源文件，该文件可以创建一个与 zlib 库链接的可执行文件。

我们可以安装调试和发布依赖项，并使用以下命令部署包的本地副本：

  $ conan install . --deployer=full_deploy --build=missing
  $ conan install . --deployer=full_deploy -s build_type=Debug --build=missing

这将创建以下文件夹

  ├──src
  ├──build
  │   ├──generators
  |         └── ZLibConfig.cmake
  ├──full_deploy
  │   ├──build
  │   │   └──cmake
  │   │       └──3.25.3
  │   │           └──x86_64
  │   │               ├──bin
  │   │
  │   └──host
  │       └──zlib
  │           └──1.2.13
  │               ├──Debug
  │               │   └──x86_64
  │               │       ├──include
  │               │       ├──lib
  │               └──Release
  │                   └──x86_64
  │                       ├──include
  │                       ├──lib

该项目是完全自包含的。它包含必要的工具（例如 cmake 可执行文件）、zlib 的头文件和编译后的库，以及必要的文件（例如 build/generators 文件夹中的 ZLibConfig.cmake），这些文件使用相对路径指向 full_deploy 中的二进制文件。

可以删除 Conan 缓存，甚至完全卸载 Conan，然后可以将该文件夹移动到计算机中的其他位置或复制到另一台计算机，假设它具有相同的操作系统、编译器等配置。

  $ cd ..
  $ cp -R development_deploy /some/other/place
  $ cd /some/other/place

并且开发人员可以使用已部署的文件

  # Commands for WINDOWS
  $ cd build
  # Activate the environment to use CMake 3.25
  $ generators\conanbuild.bat
  $ cmake --version
  cmake version 3.25.3
  # Configure, should match the settings used at install
  # If CMake>=3.23 you can also use ``cmake --preset conan-default``
  $ cmake .. -G \"Visual Studio 17 2022\" -DCMAKE_TOOLCHAIN_FILE=generators/conan_toolchain.cmake
  $ cmake --build . --config Release
  $ Release\compressor.exe
  ZLIB VERSION: 1.2.13

在 Linux 和 OSX 中重新定位环境 shell 文件

Linux 和 OSX 中的环境脚本不可重新定位，因为它们包含绝对路径，并且 sh shell 无法提供对已源代码文件的当前脚本目录的访问权限。

这应该不是一个很大的障碍，因为可以使用 sed 在 generators 文件夹中进行“查找和替换”来解决此问题

  # LINUX
  $ cd build/Release/generators
  # Fix folders in Linux
  $ sed -i 's,{old_folder},{new_folder},g' *
  # Fix folders in MacOS
  $ sed -i '' 's,{old_folder},{new_folder},g' *
  $ source conanbuild.sh
  $ cd ..
  $ cmake --version
  cmake version 3.25.3
  # If CMake>=3.23 you can use ``cmake --preset conan-default``
  $ cmake ../.. -DCMAKE_TOOLCHAIN_FILE=generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
  $ cmake --build .
  $ ./compressor
  ZLIB VERSION: 1.2.13

结论

所描述的新功能不一定是使用 Conan 包的推荐方法，但在某些情况下，无法运行 Conan 来安装开发的依赖项时，它可能很有用。我们很高兴能够通过 Conan 2.0 将此功能提供给需要它的用户。

请注意，本文中描述的方法适用于 1 个开发配置，因为生成的 CMake 文件只能支持 1 个配置（对于 Visual Studio 等多配置工具，则为调试/发布）。如果您需要支持多个操作系统或平台，则需要为每个操作系统或平台生成 1 个部署。

所介绍的方法可以非常轻松地根据您的自身需求进行自定义，因为 Conan 2.0 还实现了一些新的扩展点

如果 --deployer=full_deploy 未实现您最终所需的输出布局，或者您需要自定义其中的任何内容，可以创建自己的部署器
有关更进一步的自定义自动化功能，请查看自定义命令新框架

这是一个新功能，虽然 --deployer=full_deploy 功能适用于每个构建系统，但目前只有使用 CMakeToolchain 和 CMakeDeps 生成的 CMake 文件以及使用 VirtualBuildEnv 和 VirtualRunEnv 生成的 Windows 环境脚本是可重新定位的。对于其他构建系统，如果您不移动 full_deploy 文件夹，它可以正常工作，否则您可能需要使用 sed 策略，或考虑将其作为新功能提出。非常欢迎您的反馈，如果您有任何问题、评论或建议，请在 Github 上创建问题。