C++头文件——把它们放在一个目录中还是合并成树形结构?

11
我有一大批源代码 (OOFILE),最终将其放在 Sourceforge 上。我需要决定是否使用单个包含目录或将头文件与源树保持在一起。
我希望在推送到 SourceForge 的 svn 存储库之前做出这个决定。我预计,在此之后使用它的很多人都会直接从 SF 检出一个工作副本,因此不想更改他们的结构。
完整的源树有大约 25 个文件夹中的 262 个文件。由于符合 8.3 字符名称 (是的,它可以追溯到 Win3.1),因此许多类在一个文件中。因为我曾经使用过 ObjectMaster 进行开发,所以这从来没有打扰过我,但现在我将拆分它以符合更近期的趋势,以尽量减少每个文件中的类数。从快速浏览的 class list 看,大约有 600 个类。
OOFILE 是跨平台产品,预计可在 Mac、Windows 和各种 Unix 平台上构建。由于它始于 Mac,并且使用指向 include trees 而不是扁平的 include dirs 编译器,因此头文件与源代码一起保存。
稍后,主要是为了让一些Visual Studio用户满意,使用单个include目录重新组织了一个版本。我正在尝试在这些模型之间进行选择。
整个OOFILE产品涵盖了很多领域:
- 数据库前端 - 一系列数据库后端 - Mac和Windows的简单2D图形引擎 - 用于微不足道的html和文本列表的简单字符模式报告编写器 - 非常丰富的带有Mac和Windows预览和打印以及跨平台生成文本、RTF、HTML和XML报告的分区报告编写器 - 表单集成引擎,用于将CRUD表单绑定到数据库,实现了PowerPlant和MFC上的实现 - 跨平台实用程序类
- 文件和目录操作 - 字符串 - 数组 - XML和标记生成
许多人只想在单个平台上使用它,其中一些代码区域是纯遗留代码(例如:Classic Mac上的PowerPlant UI框架)。因此,人们似乎会欣赏不会将那些不需要的区域的头文件倒入他们的整体包含目录中。
我开始考虑将一个包含目录拆分为上述几个领域,然后意识到这听起来更像原始结构。
总之,选择似乎有:
1. 保留原始模型,所有头文件与源代码相邻 - 在项目中具有最大的灵活性,但成本是一些复杂的包含。 2. 一个包含目录,里面包含了所有内容。 3. 按领域拆分包含文件,因此使用全部内容的人可能会有大约6个目录,但纯数据库用户可能只有一个目录。

从Unix构建方面来看,推荐的结构是2。我的情况比较复杂,需要让Visual Studio和XCode用户满意(哭泣,CodeWarrior,我想念你!)。

编辑 - 所选解决方案:

我选择了在include中使用四个子目录。我开始尝试按平台进一步划分它们,但很快就变得非常混乱。

1个回答

6

个人建议选择2,如果实在迫不得已可以选择3。

但无论你选择哪种方式,请确保在构建说明中清楚说明如何设置包含路径。没有什么比难以构建更能毁掉一个开源项目的了——开发者希望快速地得到一个开箱即用的体验,如果需要折腾很多未经记录的环境变量(或类似东西),大多数开发者都会选择离开。


早期版本的Visual C++不支持相对路径,因此我们必须使用至少一个环境变量,但我知道你的意思! - Andy Dent
不是真的;-) 关于包含路径的观点是一个非常好的提醒。 - Andy Dent

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接