关于第三方库的最常见的 C++ 项目目录结构约定答案

【问题标题】：Most common C++ project directory structure convention with respect to third-party libraries关于第三方库的最常见的 C++ 项目目录结构约定
【发布时间】：2015-01-12 23:41:10
【问题描述】：

我是 C++ 的新手（学习了一些游戏编程知识），我想使用通用约定设置我的目录结构。我没有看到明确建议的主要混淆点是我放置依赖项的位置。例如，我将研究 FreeGLUT 和 FreeType。我下载的第一件事是 FreeGLUT 的 MSVC 版本，它带有一个子目录结构，如下所示：

bin/
    freeglut.dll
    x64/
        freeglut.dll
include/
    GL/
        someheaders.h ...
lib/
    freeglut.lib
    x64/
        freeglut.lib
readme.txt

我的 C# 开发人员想在我的解决方案目录中创建一个名为“Dependencies”的子目录，将所有这些内容放在它自己的子目录中，然后对任何其他库执行相同操作，类似于 NuGet 包目录，然后在构建时引用适当的位置。我不是 100% 确定，但我猜如果头文件分散在不同的子目录中，这对于引用头文件可能会很混乱，因为你不像在 C# 中那样在 C++ 中“添加引用”。

我的依赖项应该成为我项目的一部分吗？我应该将它们分成不同的基本文件夹吗？标准的做法是什么？

n.b.我了解 lib 或 dll 是一种选择（即您不会在构建中同时使用两者）

【问题讨论】：

嗯，我的问题可能与stackoverflow.com/questions/3605484/…重复
错误的焦点，考虑你将如何组织你的源代码管理。这样它仍然可以在 5 年后检出并重建完全相同的二进制文件。 C++ 编译器和链接器不会阻止您。如果您需要灵感，请查看 github 项目。
库经常在项目之间共享，因此它们很少能很好地从属于单个项目。

标签： c++

【解决方案1】：

或多或少的标准解决方案如下：

在您的主源代码控制存储库中，您只存储源文件和编译它们所需的构建系统文件。完全没有二进制依赖。
如果依赖项很难获取和安装，请创建一个辅助存储库并将依赖项放在那里。
如果您需要使用带有一些修改的外部库并且上游不接受它们，请将其完整修改的源代码树放入您的主源代码控制并将其构建过程集成到应用程序的构建过程中（in-tree fork），或将修改后的源存储在另一个存储库中（out-of-tree fork）。请注意，如果您使用 in-tree fork，大多数许可证将要求您将程序开源。与其他人，例如LGPL，你可以只发布out-of-tree fork的源代码。

这就是例如Inkscape 项目有：https://launchpad.net/inkscape 有一个主存储库，其中包含项目的完整源代码，https://launchpad.net/inkscape-devlibs 有一个单独的存储库，其中包含在 Windows 下构建所需的依赖项的二进制文件。

这样您将避免因依赖项更改而弄乱修订历史记录并将大型二进制文件存储在主树中。

【讨论】：