我正在构建一个非常基本的库，这是我计划发布的第一个项目，供其他人使用，如果他们愿意的话。因此，我想知道就组织而言，有哪些“最佳实践”。我的项目唯一可能的独特之处在于，为了在项目中使用它，用户需要扩展某些抽象类，这引出了我的第一个问题：
我的第二个问题涉及依赖关系。例如，我当前的项目依赖于 OpenGL、GLFW 和 GLEW。我应该以某种方式将它们打包到我的项目中，还是只让用户负责确保它们已安装？
编辑：有人问我的目标操作系统。我所有的依赖项都是跨平台的，所以我（也许天真地）希望我的库也可以跨平台。
感谢您的任何帮助！
这真的取决于具体情况。如果您有一些相当复杂的功能，它们包含在许多密切相关的功能中，那么一个标题是正确的解决方案。
例如，您编写了一组将某些东西绘制到屏幕上的函数，您需要一些函数来配置/设置环境，一些函数来定义和放置场景中的对象，一些函数来进行实际的绘图/处理，最后拆解，然后使用一个头文件是一个不错的方案。
在上述情况下，也可能有一个“整体”头文件，其中包含几个较小的头文件。特别是如果你有相当大的类，将它们全部放在一个文件中会变得相当混乱。
另一方面，如果你有一组处理溶解在液体中的气体的函数，另一组计算钢梁强度/承载能力的函数，以及另一组计算橡胶轮胎摩擦力的函数一个路面，那么它们可能应该有不同的标题 - 即使在“物理/力学库”中进入所有可行的功能也是如此。
在您的库中提供第三方库很少是一个好主意 - 是的，如果您想提供两个下载，一个带有“所有你需要的，只需加水”和一个“裸库”，那很好。但是我不想花费比必要时间多三倍的时间来下载您的库，因为它还包含您的代码正在使用的其他三个库，这些库已经在我的机器上。但是，请记录需要哪些库，以及在支持的平台上安装它们需要做什么（以及支持的平台是什么）。以及您测试了哪些版本的库 - 没有什么比“获取最新”更糟糕的了，只是发现需要的版本退后了两步......
（正如 Jason C 指出的那样，一旦你的代码依赖于几个不同的包，许可就会变得非常混乱，因为你的许可证必须与所有其他许可证兼容——有时这甚至是不可能的......）
您有多种选择，这实际上取决于您选择为使用您的库的开发人员提供的便利程度。
至于头文件，一般复杂度库的一般方法是拥有一个开发人员可以包含的头文件，以获取他们需要的一切。一个好的方法是，如果您有多个标头，请创建一个与您的库同名的标头（不是必需的，只是常见的）并将它#include 所有单独的标头。然后分发单个标头和单个标头。这样，您的用户可以选择#include just one 来获取所有内容，或者在必要时#include 个人。
例如在 mylibrary.h 中：
#ifndef MYLIBRARY_H
#define MYLIBRARY_H
#include <mylibrary/something.h>
#include <mylibrary/another.h>
#include <mylibrary/lastone.h>
#endif
如果您想向开发人员提供该选项，请确保您的个人标头可以独立包含（即它们#include 他们需要的所有内容）。
至于依赖项，您需要让用户负责确保它们已安装。用户正在编译他们的代码并链接到您的库，因此链接到依赖库也是用户的责任。如果您将第三方依赖项与您的库打包在一起，您将面临许多风险：
最好的办法是清楚地记录所需的依赖项。
为此，没有真正标准的“最佳实践”。任何理智的做法都是一种好的做法。