我们有一个项目需要链接libcurl和libxml2以及其他库。我们似乎基本上有两种管理这些依赖关系的策略：
要求每个开发人员在“通常”位置安装这些库，例如： /usr/lib或
在项目源代码树的专用文件夹下包含这些库的源代码。
方法1要求每个人确保在他们的系统上安装这些库，但似乎是许多开源项目使用的方法。在这样的项目中，构建将检测到这些库缺失并且将失败。
方法2可能会使项目树在某些情况下难以管理，并使编译时间更长。另外，这种方法显然可以采取太多措施。例如，我不会将编译器放在项目树下（对吗？）。
外部依赖项的最佳做法是什么？可以/应该要求每个开发人员安装某些库来构建项目吗？或者被认为最好在项目树中包含所有依赖项？
答案 0 :(得分：1)
不要打扰他们在您的代码中的确切位置。如果它们很常见，则应使用已使用的编译器/链接器（或用户通过设置变量）来处理它们。对于非常不常见的依赖项（或具有自定义/修改文件的依赖项），您可能希望将它们包含在源代码中（如果可能，由于许可等）。
如果您更喜欢它，您应该使用一些脚本（例如configure或CMake）来设置/创建正在使用的构建文件。例如，CMake允许您将不同的包（示例中为libcurl和libxml2）设置为可选和必需。在构建项目时，它将尝试找到那些，如果失败，它将询问用户。这是一个额外的步骤，可能会使构建更麻烦，但它也会使下载更快（更小的源）以及更新更容易（因为你所要做的就是重建你的程序）。
所以一般来说我会遵循方法1，如果有特殊/稀有/定制的东西被使用，接近2。
答案 1 :(得分：0)
通常的方法是拥有相应的依赖项并让开发人员安装它们。稍后，如果项目被打包到.deb或.rpm，这些数据包将需要安装相应的库，源数据包将具有-devel数据包作为依赖项。
答案 2 :(得分：0)
最佳做法是不在源代码树中包含外部库 - 而是在项目根目录中包含一个名为INSTALL的文本文件，该文件提供有关构建项目的说明，包括库依赖项列表，包括最低版本。