介绍

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”定义。这是一个定义包依赖项、源文件、如何从源文件构建二进制文件等的 Python 文件。一个包“conanfile.py”配方可以生成任意数量的二进制文件，每个二进制文件对应一个不同的平台和配置：操作系统、架构、编译器、构建类型等。这些二进制文件可以使用所有平台上的相同命令创建并上传到服务器，拥有所有包的单一事实来源，而无需为每个不同的操作系统使用不同的解决方案。

_images/conan-binary_mgmt.png

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

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

Conan 支持 Windows、Linux（Ubuntu、Debian、Red Hat、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 的公共接口。私有实现细节以及文档中未包含的所有内容都可能发生更改。

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

  • 只有每个次要版本最新的修补程序（主版本.次版本.修补程序）才受支持且稳定。

以下是一些不包含在此承诺中的内容：

  • 公共仓库，如ConanCenter，假定使用最新版本的 Conan 客户端，使用旧版本可能会导致使用新版本客户端创建的包和配方失败。建议使用您自己的私有仓库来存储生产环境中的包副本，或者作为次要替代方案，使用某种锁定机制来避免 ConanCenter 中更新并需要最新 Conan 版本的包可能导致的潜在中断。

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

  • 作为插件或钩子的扩展点的内置默认实现也可能随每次发布而更改。用户可以提供自己的实现以获得稳定性。

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

  • 标准输出流 stdout、stderr，即终端输出可能会随时更改。请勿将终端输出用于自动化。

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

  • 文档中标记为deprecated（已弃用）的任何内容都不应再使用，因为它将在下一个主要版本中完全删除。应使用其他替代方案或方法，并且如果正在使用，应尽快迁移到其他替代方案。它们将不会得到维护或修复。

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

Conan 运行需要 Python >= 3.7。Conan 将在 Python 版本达到生命周期结束 (EOL) 一年后弃用对其的支持。

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

社区

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

  • https://github.com/conan-io/conan 项目在 Github 上有大约 8.6K 颗星，并得到了 400 多名不同用户的贡献（这仅仅是客户端工具）。

  • 许多其他用户通过https://github.com/conan-io/conan-center-index 仓库为 ConanCenter 贡献配方，为流行的开源库创建包，每年贡献数千个拉取请求。

  • 在 CppLang Slack 的 #conan 频道中有超过两千名 Conan 用户，他们帮助回答问题、讨论问题和方法，使其成为整个 CppLang slack 中最活跃的频道之一。

  • 在#include<cpp> discord 中有一个 Conan 频道。