代码之家 › 专栏 › 技术社区 › Zach Burlingame

如何使用NMAW组织C++项目的项目树?

nmake project-organization build-automation

17

Zach Burlingame · 技术社区 · 17 年前

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

wxWidgets project使用以下样式:

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

赞成的意见:

欺骗:

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

Wireshark project使用此样式

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

赞成的意见:

允许在生成工具中使用更短的推理规则

欺骗:

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

nmake ,约定1在创建正确的nmake文件时引起了一些严重的问题。

减少维护整个解决方案的构建脚本的工作量。
通过使用用于签出的构建脚本来为每次提交发布媒体生成,从而促进持续集成(显然还利用了其他工具,如CruiseControl)。
使添加或删除其他项目或源文件对开发人员来说尽可能容易,并且最不容易出错。

所以我问:

还有其他的优点和缺点吗这两种方法中的哪一种?
是否有一个明确的土地只支持一个

2 回复 | 直到 12 年前

1

4

JXG Jasmynn Flores 17 年前

[部分答复。]

在“约定2:高级项目目录,键入子目录”中,您的单个con是

如果之间存在依赖关系项目中,您需要一个附加层在项目上方生成脚本的数量用于管理生成顺序的目录

如果您有大量重复的常规定义,您可能需要构建脚本的include文件,其中包含解决方案范围的常量&可以定义参数。因此,“额外的构建脚本层”无论如何都会经常发生,即使没有(直接)依赖关系。

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

2

1

Thomas L Holaday 17 年前

考虑使用 NTFS junction points

对“真实”布局使用约定2,因为它使项目易于移动。然后创建一个约定1视图:

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

现在你有。。。

/solution
  /test
    /prj1
    /prj2

... 这是理想的结果。

如果您觉得对/src或其他目录有益的话,也可以对其执行相同的操作。从约定1视图live in/solution/Test中获益的测试脚本。