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

Question

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

约定1：高级类型目录、项目子目录

例如，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 文件时引起了一些严重的麻烦。

我的主要要求/目标是：

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

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

• 通过使用构建脚本进行签出以为每次提交发布媒体生成（显然也利用 CruiseControl 等其他工具），从而促进持续集成。

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

所以我问：

• 还有其他优缺点吗 这些方法中的任何一种？
• 是否有明确的规定只偏爱一个 这些约定？

Answer 1

[部分答案。]

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

如果之间存在依赖关系 项目，你需要一个额外的层 项目上方的构建脚本 管理构建顺序的目录

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

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

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

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

Answer 2

考虑使用NTFS junction points，这样您就可以同时拥有这两个组织。快速定义：“连接点是微软对符号链接的实现，但它只适用于目录。”

对“真实”布局使用约定 2，因为它使项目易于移动。然后制作一个 Convention 1 视图：

mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test

现在你有...

/solution
  /test
    /prj1
    /prj2 

...这是想要的结果。

如果您发现 /src 或其他目录有益，您可以对它执行相同的操作。受益于约定 1 视图的测试脚本位于 /solution/test 中。