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

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

此新功能允许将 Conan 依赖项构件直接安装到您的项目文件夹中，并实现一个完全独立于 Conan 的项目，即使系统中未安装 Conan，也可以构建和运行该项目。对于某些无法使用常规 Conan 开发流程的情况，这是一个长期以来一直需要的功能。

Conan 包的常规安装和使用

下图说明了使用 Conan 安装和使用依赖项的常规方法

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

Conan 生成的文件，例如用于正确定位 Conan 缓存中依赖项的 conan_toolchain.cmake 或 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 库链接的可执行文件。

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

  $ 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 的头文件和编译后的库，以及必要的 ZLibConfig.cmake 等文件（位于 build/generators 文件夹中），这些文件使用相对路径指向 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 这样的多配置工具，则为 Debug/Release）。如果需要支持多个操作系统或平台，则需要为每个平台生成 1 个部署。

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

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

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