介绍

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 远程仓库 push-pull 的模型。

从宏观层面上讲，服务器只是存储软件包。它们不会构建或创建软件包。软件包由客户端创建，如果从源代码构建二进制文件，则该编译也由客户端应用程序完成。

_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、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 的公共接口的一部分。私有实现细节以及文档中未包含的所有内容可能会发生变化。

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

  • 仅支持每个次要版本的最新发布补丁版本（major.minor.patch）。

有些内容不包含在此承诺中

  • 公共仓库，如 ConanCenter，假定使用 Conan 客户端的最新版本，并且使用旧版本可能会导致使用较新版本客户端创建的软件包和配方失败。建议使用您自己的私有仓库来存储您自己的软件包副本以供生产使用，或者作为替代方案，使用一些锁定机制来避免 ConanCenter 中软件包的可能中断，这些软件包已更新并需要最新的 Conan 版本。

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

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

  • 使用 conan new 的软件包模板的输出可以随时更新以使用最新功能。

  • 输出流 stdout、stderr，即终端输出可以随时更改。不要解析终端输出进行自动化。

  • 文档中明确标记为 experimental 或 preview 的任何内容。

  • 文档中标记为 deprecated 的任何内容不应进行新的用法，因为它不会获得新的修复，并且将在下一个主要版本中删除。

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

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

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

社区

Conan 正在被 TomTom、Audi、RTI、Continental、Plex、Electrolux 和 Mercedes-Benz 等数千家公司以及全球数万名开发人员投入生产使用。但 Conan 的一个重要部分是，其中许多用户会回馈贡献，从而创建一个令人惊叹和乐于助人的社区