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

Question

我有大量的源代码 ( OOFILE )，我终于放在了 Sourceforge 上.我需要决定是应该使用整体包含目录还是将头文件与源代码树一起保留。

我想在推送到 SourceForge 上的 svn 仓库之前做出这个决定。我希望很多在该移动之后使用它的人会保留直接从 SF checkout 的工作拷贝，因此不想更改他们的结构。

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

OOFILE 是一款跨平台产品，预计将在 Mac、Windows 和各种 Unix 平台上构建。当它开始在 Mac 上使用时，编译器指向include trees 而不是扁平的include dirs， header 与源一起保存。

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

整个 OOFILE 产品涵盖了很多领域:

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

许多人只想在单一平台上使用它，其中一些代码区域是纯粹的遗留代码(例如:经典 Mac 上的 PowerPlant UI 框架)。因此，人们似乎希望不要将来自那些不需要的区域的 header 转储到他们的整体包含目录中。

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

总而言之，选择似乎是:

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

从 Unix 构建方面来看，recommended structure一直是 2。我的情况很复杂，因为需要让 Visual Studio 和 XCode 用户满意(闻一闻，CodeWarrior，我多么想念你!)。

编辑 - 选择的解决方案:

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

Answer 1

就我个人而言，我会选择 2，如果真的有压力的话，我会选择 3。

但是无论您选择哪个，请在构建说明中明确说明如何设置包含路径。没有什么比真正难以构建更让开源项目注定失败的了——开发人员希望获得快速的开箱即用体验，如果涉及到使用许多未记录的环境变量(或其他)，大多数都会消失。