传统上，管理C++依赖项一直是一个难题。自Conan诞生以来，我们一直致力于提供一个实用、赋能开发者并节省他们时间的工具。自Conan 1.0首次发布以来，我们见证了Conan如何成为C++生态系统中的关键组成部分，为来自各行各业的开发者构建了一个丰富的社区。在过去的几年里，C++不断发展，随之而来的是用户需求的变化。

我们一直倾听这个伟大社区的反馈，今天我们很自豪地宣布Conan 2.0的发布。

Conan 2.0，开源C和C++包管理器的最新版本，现已发布！

Conan 2.0从根本上重新设计，以更好地满足社区的需求。一些值得注意的功能包括：

  • 新的和改进的图形模型，以更好地表示传递使用需求
  • 全新编写的文档
  • 包不变性的版本
    • 版本在Conan 1.x中是可选的，但在Conan 2.0中默认启用。
    • 改进了下载、安装和更新依赖项的过程，重点关注保证不变性。
    • 更高效的上传和下载操作
  • 重新设计和改进的构建系统集成
    • 与现有CMake项目的完全透明集成
    • 支持CMake预设，简化本地工作流中CMake命令的调用
    • 所有集成（Autotools、Xcode、MSBuild）采用相同的模型，并使用generate()方法更好地隔离逻辑
  • 新的命令行界面
    • 多个Conan命令的统一界面
    • 允许多种输出格式和终端重定向。更清晰的输出。
    • 改进的、结构化的机器可读输出（json），以更好地支持CI工作流
  • 新的公共Python API
    • Conan内置命令使用的相同API现在可用于更高级的集成
  • 自定义命令
    • 用户提供的Conan子命令的能力，以扩展内置功能
    • 自定义命令可以通过众所周知的conan config install机制共享
    • 可以使用新的公共Python API来实现其他功能
  • 改进的package_id逻辑
    • 考虑包类型和特征，更有效地确定何时需要根据其依赖项的变化重新构建包
  • 全局package_id兼容性扩展
    • 能够在全局级别而不是在配方级别定义二进制兼容性
    • 可用于利用已知的启发式方法，例如，给定编译器版本的二进制文件是兼容的，并且可以链接使用同一编译器的早期版本构建的二进制文件
  • 锁定文件：简化和改进
    • 锁定文件现在被建模为排序引用列表，允许单个锁定文件用于多个配置
    • 改进了合并锁定文件、用户定义约束等工作流
  • 新的配置系统
    • 通过配置文件和命令行通过[conf]机制统一配置和控制Conan行为的能力
    • 比旧的混合环境变量结构更合理且灵活。
  • 多版本本地Conan缓存
    • 完全重新设计的缓存，允许同时存储多个配方和包版本。
    • 缩短路径，无需解决Windows上的路径长度限制
  • 新的部署器
    • 用户提供的部署策略的新功能，可以从Conan缓存复制操作到任意用户文件夹。
    • 可用于生成包含应用程序所有依赖项需求的自一致前缀，或打包依赖项以在Conan包之外分发
  • 新的可扩展性功能
    • 新的能力来自定义可用设置在settings_user.yml中，而无需修改全局settings.yml
    • 命令包装器：拦截对self.run()的调用，对外部集成（分布式编译等）很有用
    • 配置文件和配置现在支持jinja模板以实现额外的灵活性
  • 包签名
    • 实现包签名和验证的新扩展

继续阅读以了解更多关于Conan 2.0及其对您的C++项目意味着什么的信息。

简史

Conan的第一个预览版本于2016年底发布。从那时起，Conan经历了持续的显著增长：赋能团队将他们的C++项目带入DevOps时代。在2020年1月至2022年12月期间，我们看到Conan包在Artifactory中的使用率增长了5倍（JFrog软件工件现状2023），进一步表明用户群的增长持续至今。

成千上万的团队在他们的C和C++工作流中使用Conan，从初创公司到许多大型企业，包括许多财富100强企业。我们尽一切努力兑现我们对稳定性的承诺，持续向Conan 1.x系列提供更新。但随着时间的推移，这项任务变得越来越困难，因为我们努力在不破坏现有用户的情况下继续改进用户反馈。

社区多年来的反馈和经验带来了这个新的里程碑，例如：

  • 2022年，ConanCenter处理了超过5000个拉取请求
  • 每月从PyPI下载超过75万次，被指定为PyPI关键项目
  • Conan 2.0在Github上关闭了超过1000个工单
  • #CppLang中的Conan频道拥有超过2400名订阅者，始终位列最活跃的频道前列

我们一直在倾听您的声音：今天我们很自豪地宣布Conan 2.0的发布。

当今C++项目的需要

当Conan首次引入时，正值大型编译器供应商最后一次破坏其运行时库的ABI（libstdc++ ABI和Visual C++ 2015）的时候。能够对从相同源代码构建的不同二进制包进行建模一直是Conan的核心主张。从那时起，C++生态系统持续以前所未有的速度发展。

  • 编译器供应商继续实现新标准（C++ 14、17、20及更高版本）的功能，并发布更频繁的更新。我们已经成功地见证了团队如何采用Conan，使开发人员能够比以往任何时候都更快、更稳健地适应这些快速变化。
  • 现代CMake（传递使用需求的传播）持续发展并在整个生态系统中传播。随之而来的是，用户在他们的CMake项目中使用C++依赖项的需求也发生了变化。
  • 许多公司现在正在开发针对嵌入式设备上的AI/机器学习的目标，并且Apple和Microsoft现在都支持ARM64作为其桌面操作系统（macOS和Windows）的主要目标。因此，用户对支持交叉构建的需求持续增长。对于物联网应用程序以及机器人、汽车、航空、嵌入式和医疗行业尤其如此。

各种规模的团队，特别是大型团队，对Conan的采用推动了团队在其C++项目中采用现代DevOps实践的需求。如今，我们经常看到团队要求以下方面的指导：

  • CI集成，以使用Conan的平台无关抽象构建跨平台C++项目，而在过去，团队可能在不同平台上使用不同的依赖项解决方案。如何管理不断增长的平台变体组合？
  • 在多个平台上的CI系统上大规模构建依赖项。如何正确建模由于上游更改而需要重新构建的最小依赖项？如何从依赖项列表中获取信息以并行化和编排跨多个系统的包构建？
  • 鉴于配方本身会随着时间的推移而改变，如何在CI系统和开发人员之间确保可重复性？
  • 如何在开发人员在不同分支上工作所需的灵活性与生产软件的CI/CD系统对确定性需求之间取得平衡。

在过去的5年中，我们试图通过对Conan 1.x的增量更新来满足这些需求。在这个过程中，我们吸取了一些重要的教训，这些教训促使我们提出了一个主要的2.0版本，以便能够跃升到下一个层次。

经验教训

教训#1：C和C++具有挑战性

Conan 1.0具有一个相对简单的依赖项模型，该模型受Python或NPM等其他语言包管理器的启发。包可以“需要”其他包，作为一个有用的创新，我们引入了“tool_require”的概念来表达对构建工具包的依赖。但是，如果C和C++本身具有挑战性，那么构建C和C++项目则更具挑战性，并且毫不奇怪，我们了解到为C和C++进行包管理也具有挑战性。**简单的“require”模型不足以表示许多不同的场景**，例如：

  • 如何将使用需求（编译器和链接器标志）传播到 2 个库，具体取决于它们是共享库、静态库、仅限头文件库还是它们的组合。
  • 头文件的可见性是否需要传播到下游依赖项。
  • 同一个依赖关系图中可能包含同一个库的多个版本——例如，同一个库的 2 个不同版本构建为静态库，但嵌入并隐藏在 2 个不同的共享库中。

创建不同类型的“requires”，例如“tool_requires”似乎不是一个可扩展的想法，因此受到构建系统建模传递使用需求的启发，我们创建了一个模型，其中“requires”可以用几个不同的“traits”进行限定，这些“traits”定义了如何需要包以及如何将其信息传播到依赖关系图中依赖它们的其它包。通过这种方式，一个包可以定义它需要另一个包，例如 headers=True, libs=False, transitive_headers=True，这意味着它只使用库的头文件，并且在自己的头文件中使用它们，因此它们将对下游使用者可见。

这些信息可以以非常有用的方式利用，Conan 2.0 将更加高效，仅获取构建和运行所需的二进制文件（由于更好的“package_id”计算模型），但在许多情况下能够跳过下载图的大部分二进制文件，从而加快安装和构建时间。我们对新的图形模型、需求特征和新的 package_type recipe 属性的潜力感到兴奋，以及这将如何实现更好的依赖项建模和管理。

“每一次发布，我们都见证了开发链的巨大改进——我们期待着这将带给我们的重大飞跃，让我们迈向新的高度！”

Maikel van den Hurk，TomTom 高级软件工程师

经验教训 #2. C 和 C++ 是全球企业信赖的高性能语言

C 和 C++ 是全球软件产业的支柱。C 和 C++ 也是企业级软件的首选编程语言。虽然它们可能不是许多小型公司技术栈的一部分，但它们在硬件、汽车、金融、医疗、人工智能、媒体、机器人、嵌入式等关键应用中仍然具有巨大且不断增长的普及率。这也意味着各种各样的用例、流程、策略、法规和合规规则等。

因此，不可能有一个工具完全适合如此广泛的用例，扩展功能是其基本组成部分。Conan 1.X 的扩展性有限，有一个 Python API，但它只是最小程度地模拟了 CLI 命令，在实践中通常不太有用，并且由于它并非真正设计为开放的，因为它从未公开或记录过。但我们痛苦地意识到了这种需求，因为尽管它没有记录且是私有的，但许多用户报告了钩入 Conan 内部。

因此，我们决定 Conan 2.0 还将实现一个用于 C 和 C++ 包管理的框架，包括创建自定义命令的可能性，这些命令可以共享和分发（到开发团队、CI 机器等），一个新的更详细的完整 Python API 用于构建这些命令，以及一个新的可扩展的配置系统，它允许类型（列表、字典）以及高级操作，如追加/预置/取消设置。

同样，在 2.0 中添加了一组新的扩展功能，以克服我们在 Conan 1.0 中听到的一些限制。例如，二进制兼容性非常具有挑战性，并且不能针对所有情况全局定义。添加了一个新的 compatibility.py 插件，允许用户为其项目定义自己的二进制兼容性。此外，随着行业对安全性的关注不断增强，Conan 2.0 添加了一个新的包签名插件，允许对包进行签名，并且在发布后将发布使用 Sigstore 的参考实现。

“即使在 Conan 1.x 中，我们也对它如何以恰当的健壮框架和灵活性混合的方式很好地涵盖了我们的（有时非常特殊）用例感到惊讶。作为嵌入式系统开发人员，Conan 2.0 通过添加新的生成器和更细粒度的包环境，为我们提供了对构建流程的更好控制。我们还期待着新的公共 Python API 和扩展系统，这将增强我们在 C++ 构建自动化方面的能力。”

Maxime Bergantz，博世高级软件工程师

经验教训 #3：大规模 C++ DevOps

自 2016 年以来，随着 Conan 使用量的增加，问题的大小也开始增加。能够管理 C++ 依赖项，使公司能够更快地完成更多的事情，这开始产生进一步发展的愿望。然后我们了解到，我们正在进入 C++ 的 DevOps 世界，其他技术已经这样做了一段时间了。对于某些用户而言，能够在使用该图构建特定产品版本几年后准确地重现依赖关系图非常重要。为了满足此需求，Conan 引入了锁定文件。这些锁定文件变得与尝试在 CI 集群中尽可能并行地分发大型依赖关系图的构建相关。

但是，此重要工具难以管理，并且大规模实施 CI 和 DevOps 非常具有挑战性，成为许多公司能够加速交付的瓶颈。不幸的是，我们也痛苦地意识到，在不破坏 Conan 1.X 的范围内无法解决该瓶颈。

因此，我们最终非常激动地推出 2.0，它具有新的更简单且更强大的锁定文件，以及新的改进的 CI 导向工具，例如在图中更好地计算包的构建顺序，以及在图中某些内容发生变化时更好地优化依赖关系图中需要构建的内容。借助这些新工具，最终可以释放现代 DevOps 流程在 C 和 C++ 项目中的全部潜力。

“我真的很期待 Conan 2.0。通过在 2020 年启动 Conan 部落，Conan 团队确保将用户反馈纳入即将发布的版本中。我非常期待 Conan 2.0 将带来的改进的锁定文件处理。结合新的 Python API，这将大大简化我们的 CI 工作流程。”

Kerstin Keller，大陆软件开发人员

感谢社区

不用说，如果没有 Conan 社区的支持，这一切都不可能实现。我们一直以倾听用户群为荣，这是开发像这样的工具最具挑战性的方面之一。有时，对绝大多数人来说最好的东西对少数人来说却有不受欢迎的味道。我们有时需要做出艰难的决定，关于优先考虑哪些功能或支持哪些辅助项目——但总的来说，我们一直尽最大努力记住即使是最微弱的声音。

感谢来自 Conan 部落的企业级用户以及在 GitHub 问题中提问的个人，他们帮助启发了我们引入 Conan 2.0 的更改和新功能。

对于那些贡献和维护现在位于 ConanCenter 的约 1500 个配方的人——我们敬酒。Conan Center 使新手更容易尝试 Conan，同时也是如何在企业环境中大规模使用 Conan 的展示。我们希望您能加入我们，共同庆祝此次发布。

对于那些提交问题、报告错误或分享真实用例的贡献者——我们感谢您的反馈。它在将 Conan 提升到当前水平方面发挥了重要作用，我们期待在未来的旅程中继续收到您的反馈。

对于 C++ 生态系统，欢迎我们参加会议和聚会，包括在年度调查等活动中加入 Conan。我们期待很快再次见面。

如果没有 JFrog 的支持，这一切都不可能实现。开源项目对用户来说可能是免费的，但开发和支持需要大量资源。感谢您帮助将 C++ 包管理变为现实。

立即开始使用 Conan 2.0

Conan 2.0 现已可以下载。要开始使用，请访问我们的 下载部分 并开始使用 Conan 2.0 文档。

关于 ConanCenter 的说明

在今天发布之前的几个月里，社区贡献者和 Conan 团队做出了巨大努力，升级了许多 ConanCenter 配方以使其与 Conan 2.0 兼容，同时保持与 Conan 1.X 的兼容性。在发布时，已验证下载次数最多的前 100 个配方与 Conan 2.0 兼容。

在接下来的几周和几个月里，将继续努力尽可能多地将 Conan Center 配方升级到 Conan 2.0——要详细了解此任务的进展，请阅读 Conan Center 公告。