介绍

Conan 是一个用于 C 和 C++ 语言的依赖和包管理器。它是免费和开源的，可在所有平台（Windows、Linux、macOS、FreeBSD、Solaris 等）上工作，并可用于开发包括嵌入式、移动（iOS、Android）和裸金属在内的所有目标。它还可以与所有构建系统集成，如 CMake、Visual Studio (MSBuild)、Makefiles、SCons 等，包括专有系统。

它专为加速 C 和 C++ 项目的开发和持续集成而设计和优化。凭借全面的二进制管理能力，它可以为任意数量的不同包版本创建和重用任意数量的不同二进制文件（针对不同的配置，如架构、编译器版本等），并在所有平台中使用完全相同的流程。由于它是去中心化的，您可以轻松运行自己的服务器，私下托管自己的包和二进制文件，无需共享。免费的 JFrog Artifactory Community Edition (CE) 是推荐的 Conan 服务器，用于在您的控制下私下托管您的包。

Conan 成熟且稳定，坚定致力于向前兼容（非破坏性策略），并拥有一个完整团队全职致力于其改进和支持。它得到一个强大社区的支持和使用，从 ConanCenter 的开源贡献者和包创建者，到成千上万使用它的团队和公司。

开源

Conan 是免费开源的，采用宽松的 MIT 许可证。请在 https://github.com/conan-io/conan 查看源代码和问题跟踪（用于提问和支持、报告错误以及建议功能请求和改进）。

去中心化包管理器

Conan 是一个采用客户端-服务器架构的去中心化包管理器。这意味着客户端可以从不同的服务器（“远程”）获取包，也可以将包上传到这些服务器，类似于 git 的推拉模型与 git 远程仓库之间的交互。

从高层来看，服务器仅用于存储包。它们不构建也不创建包。包是由客户端创建的，如果二进制文件是从源代码构建的，编译工作也由客户端应用程序完成。

_images/conan-systems.png

上图中的不同应用程序是

  • Conan 客户端：这是一个控制台/终端命令行应用程序，包含包创建和消费的核心逻辑。Conan 客户端有一个用于存储包的本地缓存，因此您可以在离线状态下完全创建和测试包。只要不需要从远程服务器获取新的包，您也可以离线工作。

  • JFrog Artifactory Community Edition (CE) 是推荐的 Conan 服务器，用于在您的控制下私下托管您的包。它是 JFrog Artifactory 针对 Conan 包的免费社区版本，包括 WebUI、多种认证协议 (LDAP)、用于创建高级拓扑的虚拟和远程仓库、Rest API，以及用于托管任何工件的通用仓库。

  • conan_server 是一个与 Conan 客户端一同分发的小型服务器。它是一个简单的开源实现，提供基本功能，但不包含 WebUI 或其他高级功能。

  • ConanCenter 是一个中央公共仓库，社区在此贡献 Boost、Zlib、OpenSSL、Poco 等流行开源库的包。

二进制管理

Conan 最强大的功能之一是它可以为任何可能的平台和配置创建和管理预编译的二进制文件。通过使用预编译的二进制文件并避免重复从源代码构建，它为开发人员和持续集成服务器节省了大量时间，同时还提高了工件的可重现性和可追溯性。

包由“conanfile.py”定义。这是一个文件，定义了包的依赖、源代码、如何从源代码构建二进制文件等。一个“conanfile.py”包配方可以生成任意数量的二进制文件，每个文件对应不同的平台和配置：操作系统、架构、编译器、构建类型等。这些二进制文件可以在所有平台使用相同的命令创建并上传到服务器，为所有包提供单一的真理源，并且无需为每个不同的操作系统提供不同的解决方案。

_images/conan-binary_mgmt.png

从服务器安装包也非常高效。只下载当前平台和配置所需的二进制文件，而不是全部。如果兼容的二进制文件不可用，也可以在客户端从源代码构建包。

所有平台、所有构建系统和编译器

Conan 可在 Windows、Linux (Ubuntu、Debian、RedHat、ArchLinux、Raspbian)、OSX、FreeBSD 和 SunOS 上工作，并且由于其可移植性，它可能在任何可以运行 Python 的平台上工作。它可以面向任何现有平台：从裸金属到桌面、移动、嵌入式、服务器和交叉构建。

Conan 也适用于任何构建系统。内置了对最流行的构建系统的支持，如 CMake、Visual Studio (MSBuild)、Autotools 和 Makefiles、Meson、SCons 等，但这并不是使用它们的必要条件。甚至不必所有包都使用相同的构建系统：每个包可以使用自己的构建系统，并依赖于使用不同构建系统的其他包。也可以与任何构建系统集成，包括专有系统。

同样，Conan 可以管理任何编译器和任何版本。内置了对最流行的编译器的默认定义：gcc、cl.exe、clang、apple-clang、intel，并支持不同版本的配置、运行时、C++ 标准库等。此模型也可扩展到任何自定义配置。

稳定

从 Conan 2.0 及以后版本，我们承诺保持稳定性，目标是在工具和平台演进的同时不破坏用户空间。这意味着

  • 升级到后续的小版本 2.1, 2.2, …, 2.X 不应破坏现有配方、包或命令行流程

  • 如果出现破坏性变更，将被视为回归，并会恢复。

  • 错误修复不会被视为破坏性变更，依赖于这些错误不正确行为的配方和包将被视为已经损坏。

  • 只有 https://docs.conan.org.cn 中文档化的功能被视为 Conan 公共接口的一部分。私有实现细节以及未包含在文档中的所有内容都可能随时更改。

  • 兼容性始终被视为向前兼容。新的 API、工具、方法、助手可以在后续的 2.X 版本中添加。使用这些功能创建的配方和包将与早期的 Conan 版本不向后兼容。

  • 每个小版本仅支持和稳定最新的补丁版本（major.minor.patch）。

有些内容不包含在此承诺范围内

  • 公共仓库，如 ConanCenter，假设使用最新版本的 Conan 客户端，使用旧版本可能会导致使用较新版本客户端创建的包和配方失败。建议使用您自己的私有仓库来存储用于生产的包副本，或者作为次要选择，使用某种锁定机制来避免 ConanCenter 中更新并需要最新 Conan 版本的包可能造成的干扰。

  • 配置和自动工具检测，例如默认配置文件的检测（conan profile detect）随时可能更改。鼓励用户在自己的配置文件中定义配置以实现可重复性。新版本的 Conan 可能会检测到不同的默认配置文件。

  • 扩展点作为插件或钩子的内置默认实现也可能随每个版本更改。用户可以提供自己的实现以确保稳定性。

  • 使用 conan new 命令生成的包模板输出随时可能更新以使用最新功能。

  • 输出流 stdout、stderr，即终端输出随时可能更改。请勿解析终端输出来进行自动化。

  • 文档中或 Conan CLI 输出中明确标记为 experimental 或 preview 的任何内容。请阅读以下部分以了解这些标签的详细定义。

  • 文档中标记为 deprecated 的任何功能不应再使用，因为它将不会获得新的修复，并将在下一个主要版本中移除。应使用其他替代方案或方法来代替它，如果正在使用它，应尽快迁移到其他替代方案。它们将不会得到维护或修复。

  • Conan 客户端之外的其他工具和仓库

Conan 需要 Python >=3.6 才能运行。Conan 将在 Python 版本被宣布生命周期结束 (EOL) 1 年后弃用对其的支持。

如果您对 Conan 的更新、稳定性或此稳定性定义有任何疑问，请在文档问题跟踪器中报告：https://github.com/conan-io/docs。

社区

Conan 正在被 TomTom、Audi、RTI、Continental、Plex、Electrolux 和 Mercedes-Benz 等数千家公司以及全球数以万计的开发者用于生产环境。但 Conan 的重要组成部分是，许多用户会回馈社区，创造一个令人惊叹且乐于助人的社区