【问题标题】:How to manage 3rd party libraries in a multi-configuration project如何在多配置项目中管理 3rd 方库
【发布时间】:2012-12-03 13:49:51
【问题描述】:

假设您正在处理一些支持多种配置(Linux 和 Windows 构建、共享/静态链接、具有或不具有某些功能等)的项目。要构建所有这些配置,您需要不同版本的 3rd 方组件(使用 gcc 或 msvc、共享/静态、一些指定的预处理器定义等构建)。所以最终你会遇到一个问题,不仅要为你的项目管理所有这些配置,还要为你的项目正在使用的所有库管理这些配置。

是否有通用的解决方案/方法/软件来帮助管理单个项目的多个不同配置?

标准

  • 易于设置,即从头开始构建项目需要花费多少时间?
  • 易于管理,即是否难以添加新的依赖项或删除现有的依赖项?
  • 错误证明,即开发人员多久会通过更改依赖项来破坏构建?

到目前为止,我已经尝试了几种方法。

  1. 为 VCS 下的每个配置存储预构建的包。

    优点:在项目较小的情况下易于设置(更新工作副本,一切顺利)。易于管理(为每个所需的配置构建一次库)。错误证明(VCS 客户端会通知您有关工作副本的更改)。

    缺点:不适用于分布式 VCS(GIT、Mercurial 等)。存储库快速增长,最终一个简单的“克隆”操作将是无法容忍的。您最终还下载了很多您并不真正需要的东西(即,如果您使用的是 linux,则为 windows 库)。如果您正在实现库,那么您的库的用户将通过将其集成到他们的项目中来继承所有这些问题。

  2. 存储库源而不是预构建的包。

    优点:易于设置。

    缺点:添加新库非常痛苦。您需要为每个配置提供构建脚本和源代码补丁。但这只是冰山一角。你的依赖有它们自己的依赖,它们有它们自己的,依此类推……你很有可能最终得到一个像 Gentoo 发行版这样的东西:)

  3. 在外部服务器的某处存储一个存档或只是一个包含预构建包的文件夹。

    优点:解决问题...有点。

    缺点:设置并不容易(您必须手动复制存档)。不太容易管理(您必须手动将每个库添加到服务器)。没有变化的历史。不防错,因为很容易忘记在服务器上放一些东西,或者删除一些有用的东西。

    略微改进的方法:您可以使用集中式 VCS(例如 SVN)来存储所有 3rd 方库,这样会更容易使用。但是,如果您将其用作简单的文件存储,您仍然没有集中的更改历史记录,或者如果您将其用作子存储库,您将获得一个包含许多不必要库的巨大存储库。

【问题讨论】:

  • 当你下载它们的源代码时,我使用的大多数 3rd 方库都带有它们的所有依赖项,所以它们只是构建。但正如你所提到的,这使得它们比它们可能需要的大得多。我个人编写了一个脚本来克隆/签出/下载这些库到附近的文件夹,然后我将它们构建为我自己的源代码构建过程的一部分。最烦人的是当这些库附带一个构建系统时,它会强制您启动 IDE 并按下按钮。
  • @enobayram 什么样的构建系统迫使您“启动 IDE 并按下按钮”?你如何处理这些?我的意思是,您是手动按下按钮还是使用一些自动解决方案?
  • @kol 一些库为特定的 IDE(例如 codelite)分发“项目文件”,而不是像 cmake 这样的适当的跨平台构建系统。据我所知(因为我已经搜索并找不到任何东西),没有办法从命令行告诉codelite来构建项目,所以你需要启动它并按“构建”。

标签: c++ version-control


【解决方案1】:

当您遇到此类问题时,您必须学习并开始使用Configuration Management 工具(除了您选择的 SCM 的常用技术)。 CM 是过程,使用一些配置管理工具是这个过程的一部分。

目前我们有多种不同的 CM 工具可供选择,您可以在其中选择最适合或只是首选。从我的观点来看,Chef 是“每个人的最佳选择”,您的里程可能会有所不同

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多