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