一个开源项目将如何处理外部依赖关系？

当一个人编写一个开源项目并使用Google Code或GitHub，并想使用Lua之类的库时，应该怎么做？

• 应该在存储库中包含依赖项吗？
• 应该从与项目其余部分相同的构建脚本中构建依赖关系，还是从单独的构建脚本中构建依赖关系？

鉴于该库在编译之前不需要安装。

我强烈建议您阅读有关子模块的Git文档；假设您所有的源都使用Git，它就解决了这个问题。如果没有，您可以随时设置一个git repo以进行集成。这项工作是微不足道的，而且回报是巨大的。

应该在存储库中包含依赖项吗？

我认为依赖项应始终包含在存储库中，只要包含它们不违反任何使用条款即可。除了可以在进行构建之前手动找到正确的依赖项的正确版本之外，没有什么比这更令人烦恼了。当然，如果您有自动化的工具可以轻松地做到这一点，可以找到并下载正确的依赖项，那么这很容易，但是如果您当前未连接到网络或者服务器关闭或依赖项的项目，该怎么办？已经完全停产并脱机了吗？如果可能，请始终包括依赖项。

应该从与项目其余部分相同的构建脚本中构建依赖关系，还是从单独的构建脚本中构建依赖关系？

除非有充分的理由从源代码进行编译，否则请使用预编译版本。

为什么不在构建脚本中提供选项？一个简单的开关，用于选择是否还应该编译依赖项。如果用户也选择编译依赖关系，则只需从产品的构建脚本中调用他们自己的构建脚本。因此，用户可以手动调用依赖关系的构建脚本，也可以选择创建所有内容的完整构建。但是，如果没有充分的理由从源代码进行编译，我只是将依赖项作为二进制文件提供。我认为在开放源代码世界中，有些许可证要求您将源代码与产品一起分发，但这并不意味着您无法对其进行预编译。

简而言之：尽可能提供一个完整的独立工作包。这将为您的用户提供最大的便利。

这可能适用于您的用例，也可能不适用于您的用例，但是我们在工作中要做的是在每个分支中都包含一个“ References”文件夹。我们在这里放置第三方DLL。这会导致源代码控制中相对不变的二进制文件大量重复，但是存储成本低廉，并且每个分支和标签在任何时候都具有其期望的依赖项（和版本！）。

我们自己预先编译依赖项，然后将已编译的二进制文件移到该文件夹​​中。我们自己的内部共享库也采用这种方式。这样，相同的技术就可以用于预编译的专有库，开源库和内部库。

至于现在我已经重新阅读了，实际上回答了您的问题，做了同样的事情，仅提及您的项目使用了预编译的1.3.5版本的Lua。

应该在存储库中包含依赖项吗？

如果此依赖关系是产品不可分割的一部分（源依赖关系），而不是二进制依赖关系，则可以在存储库中引用该引用（通过任何可用于SCM方法的引用），可以单独解决该依赖关系

应该从与项目其余部分相同的构建脚本中构建依赖关系，还是从单独的构建脚本中构建依赖关系？

没关系。您可以根据自己的需求（速度/透明度/可管理性等）选择任何一种方法

作为Eclipse商店，我们刚刚开始使用Buckminster来管理我们的构建/组装/部署过程。

我们的第一步是拔出所有现有的依赖库，让buckminster负责实现正确的库。这使得部署更快，更小。

下一步将把我们的整体svn存储库移至一系列模块化git存储库。

我不知道buckminster与git子模块（或针对此问题的Mercurial子仓库）集成的程度如何，但是很高兴buckminster对于任何给定组件所使用的VCS都是不可知的。