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

Question

我正在启动一个新的 C 项目，该项目主要基于 OSS。它还将出现在 SourceForge 上，我想借此机会学习组织此类代码的既定最佳实践。我正在使用 libcurl 和 libz 等库，并将使用 MinGW 和 MSYS 对其进行编译。

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

• lib，因为它们是库。然而，“lib”在 UNIX 世界中具有不同的含义。
• src，因为它们是源文件。
• 3rdparty，因为不是我写的。

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

我该怎么办？是否有我应该遵循的既定惯例？它们被写在某处吗？

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

请 不 将第三方源代码与您的代码一起提供，无论是在源代码中还是静态链接到二进制文件中，或者以任何其他方式。这只会干扰相同的其他副本，并且当库需要修复时不会得到更新。请务必告诉用户需求是什么（并跟上库中 API 的变化！）。自编译用户将确保获得依赖项，发行版将确保您的包与他们发布的版本兼容。