简介

Conan 是 C 和 C++ 语言的依赖和包管理器。它是免费和开源的，可在所有平台（Windows、Linux、macOS、FreeBSD、Solaris 等）上运行，可用于开发所有目标，包括嵌入式、移动（iOS、Android）和裸机。它还与所有构建系统集成，如 CMake、Visual Studio (MSBuild)、Makefile、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 和 Makefile、Meson、SCons 等，但这不是使用任何这些构建系统的要求。甚至不必所有包都使用相同的构建系统：每个包都可以使用自己的构建系统，并依赖于使用不同构建系统的其他包。也可以与任何构建系统集成，包括专有的构建系统。

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

稳定

从 Conan 2.0 开始，我们致力于稳定性，目标是在发展工具和平台的同时不破坏用户空间。这意味着

  • 迁移到以下次要版本 2.1、2.2、…、2.X 绝不应破坏现有配方、包或命令行流程

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

  • Bug 修复不会被认为是破坏性的，依赖于此类 Bug 的不正确行为的配方和包将被视为已损坏。

  • 只有https://docs.conan.org.cn中记录的功能才被认为是 Conan 公共接口的一部分。私有实现细节和文档中未包含的所有内容可能会发生更改。

  • 兼容性始终被认为是向前的。可以在以下 2.X 版本中添加新的 API、工具、方法、助手。使用这些功能创建的配方和包将与早期 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 将在这些版本被声明为生命周期结束 (EOL) 后 1 年弃用对 Python 版本的支持。

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

社区

成千上万家公司（如 TomTom、Audi、RTI、Continental、Plex、Electrolux 和 Mercedes-Benz）以及全球数以千计的开发人员都在生产中使用 Conan。但 Conan 的一个重要组成部分是，许多用户会贡献回来，创建一个令人惊叹且有帮助的社区