C ++头文件 - 将它们放在一个目录或合并在一个树结构？ [英] C++ Header files - put them in one directory or merged in a tree structure?

问题描述

我有大量的源代码（ OOFILE ），我最后会 打开 Sourceforge 。我需要决定是否应该使用一个单片包含目录或保持头文件与源树。

我想在SourceForge上推送到svn repo之前做出这个决定。我期望很多人使用它之后，移动将保持一个工作副本直接从SF检出，因此不会改变他们的结构。

完整的源代码tree在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


• 跨平台实用程序类
  
  
  
  • 文件和目录处理
  
  
  • 字符串
  
  
  • $ b
  • XML和标记生成
  
  

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

我开始考虑将一个include目录分成几个

总之，这些选择似乎是：

1. 保留原始模型，所有标头都与源 - 最大灵活性相邻，包含在项目中。


2. 一个包含目录， li>
   
3. 拆分包括按域，因此可能有大约6个目录用于使用该批次的用户，但纯数据库用户可能只有一个目录。

从Unix版本方面，推荐的结构已经是2.我的情况是复杂的，因为需要保持Visual Studio和XCode用户的快乐（嗅，CodeWarrior，我怎么错过你！）

编辑 - 所选解决方案：

我使用四个子目录。

解决方案

我个人认为我会用2 ，或3如果真的推。

但是无论您选择哪一个，请在构建指令中清楚地说明如何设置包含路径。没有什么比一个开源项目更糟糕的是，开发人员想要一个快速的开箱即用的体验，如果它涉及到许多无文档的环境变量（或其他），大多数都会消失。 p>

I have a substantial body of source code (OOFILE) which I'm finally putting up on Sourceforge. I need to decide if I should go with a monolithic include directory or keep the header files with the source tree.

I want to make this decision before pushing to the svn repo on SourceForge. I expect a lot of people who use it after that move will keep a working copy checked out directly from SF so won't want to change their structure.

The full source tree has about 262 files in 25 folders. There are a lot more classes than that suggests as due to conforming to 8.3 character names (yes it dates back to Win3.1) many classes are in one file. As I used to develop with ObjectMaster, that never bothered me but I will be splitting it up to conform to more recent trends to minimise the number of classes per file. From a quick skim of the class list, there are about 600 classes.

OOFILE is a cross-platform product expected to be built on Mac, Windows and assorted Unix platforms. As it started life on Mac, with compilers that point to include trees rather than flat include dirs, headers were kept with the source.

Later, mainly to keep some Visual Studio users happy, a build was reorganised with a single include directory. I'm trying to choose between those models.

The entire OOFILE product covers quite a few domains:

• database front-end
• range of database backends
• simple 2D graphing engine for Mac and Windows
• simple character-mode report-writer for trivial html and text listing
• very rich banding report-writer with Mac and Windows Preview and Printing and cross-platform generation of text, RTF, HTML and XML reports
• forms integration engine for easy CRUD forms binding to the database, with implementations on PowerPlant and MFC
• cross-platform utility classes
  • file and directory manipulation
  • strings
  • arrays
  • XML and tag generation

Many people only want to use it on a single platform and some of those code areas are pure legacy (eg: PowerPlant UI framework on classic Mac). It therefore seems people would appreciate not having headers from those unwanted areas dumped in their monolithic include directory.

I started thinking about having an include directory split up into a few of the domains above and then realised that was sounding more like the original structure.

In summary, the choices seem to be:

1. Keep original model, all headers adjacent to source - max flexibility at cost of some complex includes in projects.
2. one include directory with everything inside
3. split includes by domain, so there may be about 6 directories for someone using the lot but a pure database user would probably have a single directory.

From a Unix build aspect, the recommended structure has been 2. My situation is complicated by needing to keep Visual Studio and XCode users happy (sniff, CodeWarrior, how I doth miss thee!).

Edit - the chosen solution:

I went with four subdirectories in include. I started trying to divide them up further by platform but it just got very noisy very quickly.

解决方案

Personally I would go with 2, or 3 if really pushed.

But whichever you choose, please make it crystal clear in the build instructions how to set up the include paths. Nothing dooms an open source project more than it being really difficult to build - developers want a quick out-of-the-box experience and if it involves faffing around with many undocumented environment variables (or whatever) most will simply go away.

这篇关于C ++头文件 - 将它们放在一个目录或合并在一个树结构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！