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

我有大量的源代码(OOFILE),我最终将它放在Sourceforge上.我需要决定是否应该使用单片包含目录或将头文件与源树保持一致.

我想在推送到SourceForge上的svn repo之前做出这个决定.我希望很多人在移动后使用它会直接从SF中检出工作副本,所以不想改变它们的结构.

完整源代码树在25个文件夹中有大约262个文件.由于符合8.3字符名称(是的,它可以追溯到Win3.1),因此有很多类比所表示的要多,所以很多类都在一个文件中.正如我以前用ObjectMaster开发的那样,从来没有打扰过我,但我会将其拆分以符合最近的趋势,以最大限度地减少每个文件的类数.从课程列表的快速浏览中,大约有600个课程.

OOFILE是一款跨平台产品,预计将在Mac,Windows和各种Unix平台上构建.当它开始在Mac上生活时,编译器指向包括树而不是平面包括dirs,标题与源保持一致.

后来,主要是为了让一些Visual Studio用户满意,使用单个include目录重新构建了一个构建.我试图在这些模型之间做出选择.

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

数据库前端

数据库后端范围

适用于Mac和Windows的简单2D图形引擎

简单的字符模式报表编写器,用于简单的html和文本列表

非常丰富的绑定报告编写器,包括Mac和Windows预览和打印以及跨平台生成的文本,RTF,HTML和XML报告

表单集成引擎,用于轻松将CRUD表单绑定到数据库,并在PowerPlant和MFC上实现

跨平台实用程序类

文件和目录操作

字符串

阵列

XML和标签生成

许多人只想在单一平台上使用它,其中一些代码区域是纯粹的遗产(例如:经典Mac上的PowerPlant UI框架).因此,似乎人们会欣赏不会在其整体包含目录中转储那些不需要的区域的标题.

我开始考虑将一个include目录拆分为上面的一些域,然后意识到这听起来更像原始结构.

总之,选择似乎是:

保留原始模型,所有标题与源相邻 - 最大的灵活性,以某些复杂的成本包含在项目中.

一个包含内部所有内容的目录

split包含在域中,因此对于使用该批次的人可能有大约6个目录,但纯数据库用户可能只有一个目录.

从Unix构建方面来看,推荐的结构是2.我的情况很复杂,需要保持Visual Studio和XCode用户满意(嗅探,CodeWarrior,我多么想念你!).

编辑 - 选择的解决方案:

我选择了四个子目录.我开始试图通过平台进一步划分它们,但它很快就会非常嘈杂.

就个人而言,如果真的被推,我会选择2或3.

但无论您选择哪种方式,请在构建说明中清楚地了解如何设置包含路径.没有什么比开源项目更难以构建 - 开发人员需要快速的开箱即用体验,如果涉及到许多无证件的环境变量(或其他),那么大多数都会消失.