如何使用nmake为C++项目组织项目树？

Question

组织项目文件似乎有两个主要的约定,然后是许多变体.

惯例1:高级类型目录,项目子目录

例如,wxWidgets项目使用以下样式:

/solution
   /bin
      /prj1
      /prj2
   /include
      /prj1
      /prj2
   /lib
      /prj1
      /prj2
   /src
      /prj1
      /prj2
   /test
      /prj1
      /prj2

优点:

• 如果存在项目依赖项,则可以从单个文件管理它们
• 平面构建文件结构

缺点:

• 由于test有自己的头文件和cpp文件,因此当您为EXE文件而不是库生成单元测试应用程序时,它们需要包含您正在测试的应用程序中的目标文件.这需要您创建推理规则并扩展所有源文件的相对路径.
• 重用另一个解决方案中的任何项目需要您从树结构中提取适当的文件并修改任何构建脚本

惯例2:高级项目目录,类型子目录

例如,Wireshark项目使用此样式

/solution
   /prj1
      /bin
      /include
      /lib
      /src
      /test
   /prj2
      /bin
      /include
      /lib
      /src
      /test

优点:

• 项目本身在其文件夹中是自包含的,使其更易于移动和重用
• 允许在构建工具中使用更短的推理规则
• 促进分层构建脚本

缺点:

• 如果项目之间存在依赖关系,则需要在项目目录上方添加一层构建脚本来管理构建顺序

我们目前正在使用我们项目的惯例1,到目前为止它已经运作得相当好.现在,我正在添加单元测试(通过CxxTest)并使用nmake促进迁移到持续集成,约定1在创建正确的nmake文件时引起了一些严重的麻烦.

我的主要要求/目标是:

• 降低维护整个解决方案的构建脚本的工作量.

• 在其他项目的解决方案中分离项目及其构建步骤.

• 通过使用构建脚本进行签出以便为每次提交释放媒体生成,从而促进持续集成(显然也利用其他工具,如CruiseControl).

• 为开发人员添加或删除其他项目或源文件尽可能简单且最不容易出错.

所以我问:

• 这两种方法都有其他优缺点吗？
• 有没有一个明确的agrument只赞成这些约定之一？

Answer 1

[部分答案。]

在“约定 2：高级项目目录，类型子目录”中，您的唯一缺点是

如果项目之间存在依赖关系，则需要在项目目录之上添加一层构建脚本来管理构建顺序

在许多项目中，这也可以被视为专业人士。

如果您有很多重复的一般定义，则可能需要构建脚本的包含文件，其中可以定义解决方案范围的常量和参数。因此，即使没有（直接）依赖关系，“构建脚本的附加层”无论如何都会经常发生。

这是一个优点，因为在构建中仍然有更多模块化方法的空间。另一方面，如果您想在另一个不相关的解决方案中重用项目，则需要编写不同的定义文件。（另一方面，如果整个解决方案只有一个构建文件，如约定 1 所示，您将需要不同的构建脚本。）至于您的维护要求，（IMO）非常依赖于项目。

我的感觉倾向于第二次公约，但距离明显的胜利还很远。事实上，您在公约 1 方面的经验（直到最近一直运行良好）可能是最大的优点：具有特定组织经验的团队是一项宝贵的资产。