滥用“图书馆”一词答案

【问题标题】：Abusing the word "library"滥用“图书馆”一词
【发布时间】：2010-03-29 09:16:16
【问题描述】：

我在 SO 和其他地方看到了很多关于“维护 VCS 中的公共库”。也就是说，项目 foo 和 bar 都依赖于 libbaz，提问者想知道他们应该如何导入源将 libbaz 导入每个项目的 VCS。

我的问题是：WTF？如果 libbaz 是一个库，那么 foo 不需要它源代码。有一些设计合理的库以这种方式使用（例如 gnulib），但大部分是 foo 和 bar 应该只是链接到图书馆。

我想我的想法是：如果您将库的源代码剪切并粘贴到你自己的源代码树，那么你显然不关心未来的更新去图书馆。如果您关心更新，那么只需链接到库并信任库维护者来维护稳定的 API。

如果您不相信 API 会保持稳定，那么您不能盲目无论如何都要更新你自己的源代码副本，那么得到了什么？

总结一下这个问题：为什么有人想要维护一份项目源代码中的库，而不仅仅是链接该库并要求它作为依赖项？

如果唯一的答案是“不想要依赖”，那么为什么不只是将库的副本与您的应用程序一起分发，但保留它们完全分开？

【问题讨论】：

您能否将其格式化为更具可读性？
另外，请注意您说的是诸如 C 之类的语言。在 PHP 或 Ruby 等语言中，将外部库作为项目的一部分是很有意义的。此外，Git 有“子模块”的概念，这对此有很大帮助。
我刚刚格式化了文本，得到了 75%。但它现在更具可读性。
PHP 和 Ruby 是否不允许像 Perl 和 Python 那样导入模块？他们肯定有这种事情的机制吗？
@William，有可能，但会出现各种不兼容的情况。您图书馆的用户想要开箱即用的东西。还有其他一些情况，当一个库依赖于最近的“东西”，而另一个不能使用最近的“东西”时？用户此时应该做什么？

标签： version-control build-process dependencies

【解决方案1】：

使用供应商分支来控制第 3 方依赖项是 Subversion 书中的discussed in some depth。据我了解，基本优势是保证为所有开发人员提供稳定的 API 和统一的库，以及在同一版本控制系统中控制内部自定义修改的能力。

【讨论】：

您可以通过不安装更新版本的库来保证稳定的 API。如果要进行自定义修改，则应分叉该库。尝试使用这样的 VCS 管理依赖项让我觉得有点疯狂。
分叉库意味着您放弃所有未来的改进。使用供应商分支意味着您可以保留您的修改，同时仍然获得更新版本的供应商代码。这可能会导致问题，但我不知道在不断变化的库之上维护用户 mod 的更好方法。

【解决方案2】：

在我现在正在处理的项目中，我们有主要代码（在一个 Subversion 项目中）和大量来自不同地方的各种库，这些库位于它们自己的 Subversion 模块中。 Visual Studio 解决方案为每个项目维护单独的项目，并在最后将它们链接在一起。如果我们在 Unix 或类似的操作系统上工作，我们会做同样的事情。

我看到的唯一缺点是我有时会忘记更新更改更频繁的库之一，并且我的代码在我注意到这一点之前无法编译。如果我们将库放在同一个模块中，那么我们就不会有这个问题。（并不是说我会那样做。灵活性的提升以及在不同的主要项目中使用不同库的能力实在是太棒了。）

这里的 API 是一个红鲱鱼：要么保持不变，要么发生变化，如果发生变化，我们必须以任何一种方式更新主代码。源库与二进制库的问题也是如此（我们要么用主项目编译它们，要么不编译）。

【讨论】：