C++ 头文件 - 将它们放在一个目录中还是合并到树结构中？

Question

我有大量源代码 (OOFILE)，我终于将它们放在 Sourceforge 上。我需要决定是否应该使用整体包含目录或将头文件保留在源代码树中。

我想在推送到 SourceForge 上的 svn 存储库之前做出这个决定。我希望在迁移之后使用它的很多人会直接从 SF 签出工作副本，因此不想改变他们的结构。

完整的源代码树在 25 个文件夹中有大约 262 个文件。由于符合 8.3 字符名称（是的，它可以追溯到 Win3.1），因此类比所建议的要多得多，因此许多类都在一个文件中。正如我过去使用ObjectMaster 开发的那样，这从来没有打扰过我，但我将把它拆分以符合最近的趋势，以尽量减少每个文件的类数量。快速浏览一下class list，大约有 600 个课程。

OOFILE 是一个跨平台产品，预计将在 Mac、Windows 和各种 Unix 平台上构建。当它开始在 Mac 上运行时，编译器指向 include 树 而不是平面 include dirs，标头与源代码一起保存。

后来，主要是为了让一些 Visual Studio 用户满意，使用单个 include 目录重新组织了构建。我正在尝试在这些模型之间进行选择。

整个OOFILE产品涵盖了相当多的领域：

• 数据库前端
• 数据库后端范围
• 适用于 Mac 和 Windows 的简单 2D 图形引擎
• 简单的字符模式报告编写器，用于简单的 html 和文本列表
• 具有 Mac 和 Windows 预览和打印以及跨平台生成文本、RTF、HTML 和 XML 报告的功能非常丰富的报告编写器
• 表单集成引擎可轻松将 CRUD 表单绑定到数据库，并在 PowerPlant 和 MFC 上实现
• 跨平台实用程序类
  • 文件和目录操作
  • 字符串
  • 数组
  • XML 和标签生成

许多人只想在单一平台上使用它，其中一些代码区域是纯遗留的（例如：经典 Mac 上的 PowerPlant UI 框架）。因此，似乎人们会喜欢不将那些不需要的区域的标头转储到他们的整体包含目录中。

我开始考虑将包含目录拆分为上述几个域，然后意识到这听起来更像原始结构。

总的来说，选择似乎是：

1. 保留原始模型，所有标题都与源相邻 - 以项目中的一些复杂包含为代价实现最大灵活性。
2. 一个包含所有内容的包含目录
3. 按域拆分包含，因此可能有大约 6 个目录供使用该批次的人使用，但纯数据库用户可能只有一个目录。

从 Unix 构建方面来看，recommended structure 是 2。我的情况很复杂，因为需要让 Visual Studio 和 XCode 用户满意（嗅探，CodeWarrior，我多么想念你！）。

编辑 - 选择的解决方案：

我选择了 four subdirectories in include。我开始尝试按平台进一步划分它们，但很快就变得非常嘈杂。

Answer 1

我个人会选择 2，如果真的被推的话，我会选择 3。

但无论您选择哪种方式，请在构建说明中明确说明如何设置包含路径。没有什么比构建一个开源项目更难了——开发人员想要一种快速的开箱即用的体验，如果它涉及到许多未记录的环境变量（或其他），大多数人都会简单地消失。