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

Question

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

我将分发我正在使用的所有库的源代码副本，因此下载源代码的人不必去寻找依赖项。我该怎么称呼我存储库的目录？到目前为止，我在犹豫之间犹豫不决：

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

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

我应该怎么做？我应该遵循既定的惯例吗？他们是在某处写下来的吗？

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

请不使用您的代码发送第三方来源，无论是在源代码中还是静态链接到二进制文件中，或以任何其他方式。这只会干扰其他副本，并且在库需要修复时不会更新。告诉用户需求是什么（并跟上库中的API更改！）。自编译用户将确保获取依赖项，分发将确保您的包使用它们发布的版本。