组织C项目代码及其外部库的最佳方式是什么？

Question

我正在开始一个新的C项目，主要是基于OSS的。它也将在SourceForge上，我想借此机会学习组织这类代码的最佳实践。我使用libcurl和libz这样的库，并使用MinGW和MSYS编译它。

我将分发我使用我的projet所有库的源代码，因此下载源代码的人不必去啄食并寻找依赖关系。我应该将这些库存储在哪个目录中？到目前为止，我犹豫之间：

• lib，因为它们是库。但是，'lib'在UNIX世界中具有不同的内涵。
• src，因为它们是源文件。
• 第三方，因为我没有写它。

我应该在哪里编译这些库？我应该简单地配置并将它们安装到系统根目录下，还是应该建立一个目录，在这个目录中所有库都应该编译并链接到该目录？显然，这将对我的Makefile产生影响。

我应该怎么办？有没有建立我应该遵循的约定？他们是否写下某个地方？

Answer 1

首先，对于外部图书馆我会使用vendor，但这只是一个偏好。

其次，我不认为在没有用户知识的情况下将其他库安装在系统根目录下是一个好主意。最重要的是因为这将与这些库的后期安装版本冲突。所以我认为这些库的最佳位置应该与应用程序在同一个目录中。

您也可以将这些库静态编译到您的程序中。

Answer 2

在之前的工作中，标准是将它们安装在名为3rdparty的目录中，并在那里构建库（在第三方/ LIBNAME/Debug等中）。

Answer 3

我们使用带有_ext或_EXT后缀（即MyProject_EXT）的东西来表示它是我们项目的外部存储我们链接的外部包的源代码。

我同意彼得。外部库不应该内置到系统根目录中，因为它们可能会导致冲突。我会在他们的目录中构建它们，然后将它们安装到/ lib目录（或者可能是/ extlib）中，该目录对应用程序是唯一的，并在那里链接到它们。

Answer 4

请不要将您的代码的源代码或静态链接到二进制文件或任何其他方式的第三方来源。这只会干扰同样的其他副本，并且在图书馆需要修复时不会更新。告诉用户需求是什么（并且跟上库中的API更改！）。一个自编译用户将确保获得依赖关系，一个发行版将确保你的包使用他们发布的版本。