build-automation - 如何使用 nmake 组织 C++ 项目的项目树？

Question

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

约定一:高级类型目录、项目子目录

例如，wxWidgets项目使用这种风格:

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

优点:

如果有项目依赖，可以从单个文件

进行管理

平面构建文件结构

缺点:

由于 test 有自己的头文件和 cpp 文件，当您为 EXE 文件而不是库生成单元测试应用程序时，它们需要包含 object files从您正在测试的应用程序。这需要您创建推理规则并扩展所有源文件的相对路径。

在另一个解决方案中重用任何项目需要您从树结构中提取正确的文件并修改任何构建脚本

约定2:高级项目目录，类型子目录

例如， Wireshark项目使用这种风格

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

优点:

项目本身在其文件夹中是独立的，使它们更易于移动和重用

允许在构建工具中使用更短的推理规则

促进分层构建脚本

缺点:

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

我们目前在我们的项目中使用约定 1，到目前为止它运行良好。现在，我正在添加单元测试(通过 CxxTest)并使用 nmake 促进向持续集成的迁移, 约定 1 在创建正确的 nmake 文件时引起了一些严重的麻烦。

我的主要要求/目标是:

减少维护整个解决方案的构建脚本的工作量。

将解决方案中的项目及其构建步骤与其他项目分离。

通过使用用于 checkout 的构建脚本来促进持续集成，以发布每次提交的媒体生成(显然也利用其他工具，例如 CruiseControl)。

使添加或删除其他项目或源文件对开发人员来说尽可能容易且不易出错。

所以我问:

是否还有其他优点和缺点
这些方法中的任何一种？

是否有一个明确的主张只偏爱一个
这些约定？

Answer 1

[部分答案。]

在“约定 2:高级项目目录，键入子目录”中，您的单一骗局是

If there are dependencies between projects, you need an additional layer of build scripts above the project directories to manage the build order

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

如果您有很多重复的通用定义，可能需要一个包含文件用于构建脚本，其中可以定义解决方案范围的常量和参数。所以“额外的构建脚本层”无论如何都会经常发生，即使没有(直接)依赖关系。

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

我的感觉倾向于第 2 号公约，但这远非明显的胜利。事实上，直到最近还运行良好的第 1 号公约的经验可能是最大的优点:在某个组织有经验的人组成的团队是一项宝贵的 Assets 。