建议保持大型C ++项目模块化?

时间:2010-04-04 22:32:45

标签: c++ open-source shared-libraries libraries modularity

我们的团队正在进入规模更大的项目,其中许多项目都使用了几个开源项目。

任何建议或最佳做法可以使图书馆和互联网相对模块化并在新版本发布时轻松升级?

换句话说,假设您创建的程序是开源项目的一个分支。随着两个项目的增长,维护和共享核心更新的最简单方法是什么?

关于我的要求的建议只是请......我不需要“你应该这样做”或“你为什么”...谢谢。

2 个答案:

答案 0 :(得分:6)

对于开源项目的克隆,您最大的麻烦之一将是根据上游来源保持同步/修补。您可能不关心新功能,但您肯定需要应用关键错误修复。

我的建议是将这些内部项目小心地包装到共享库中,这样如果ABI没有被更改破坏,您可以或多或少地无痛地升级这些部分。

还有一件事 - 如果您在开源项目中发现并修复了错误 - 请不要自行修复。上游推送补丁。这将使项目更好,并将节省您与新版本合并的日子。

答案 1 :(得分:4)

按优先顺序

  1. 尽可能少地对第三方库进行更改。尝试并绕过代码中的限制。记录您的更改,然后提交补丁。
  2. 如果您无法克服其限制,请将您的更改作为补丁提交(这可能是某些项目的冰川节奏的理想主义)。
  3. 如果您不能做其中任何一项,请记录您在集中位置更改的内容,以便为新版本进行集成的穷人可以弄清楚您正在做什么,以及是否进行了更改仍然需要。
  4. 1和2是非常优选的(但是,分别是快速和非常慢),而第三个选项只会导致头痛和错误,因为您的代码库偏离了依赖项的代码库。在我的代码中,我甚至没有在IDE中加载第三方代码,除非我必须仔细阅读头文件。这消除了改变不是我的东西的诱惑。

    就模块化而言,这假设您使用的是相对稳定的第三方库,只能编程到面向公众的界面。仅仅因为你有源代码并不意味着你必须在代码中使用它。这应该允许更新基本上是拖放。现在,这是完全理想化的,但它是我努力使用的代码。