如何使用nmake为C ++项目组织项目树? [英] How to organize the project tree for a C++ project using nmake?

查看:260
本文介绍了如何使用nmake为C ++项目组织项目树?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

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

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

优点:

  • 如果存在项目依赖项,则可以从一个文件中对其进行管理
  • 平面构建文件结构

缺点:

  • 由于测试具有其自己的头文件和cpp文件,因此当您为EXE文件而不是库生成单元测试应用程序时,它们需要包含 Wireshark 项目使用这种样式

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

    优点:

    • 项目本身是独立的,位于其文件夹中,这使它们更易于移动和重复使用
    • 允许在构建工具中使用更短的推理规则
    • 促进分层构建脚本

    缺点:

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

    我们目前在我们的项目上使用约定1,到目前为止,它运行良好.现在,我正在添加单元测试(通过CxxTest)并使用解决方案

[部分答案.]

在惯例2:高级项目目录,键入子目录"中,您的一个缺点是

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

在许多项目中,这也可以看作是专业人士.

如果您有很多重复的通用定义,则可能需要构建脚本的包含文件,其中解决方案范围的常量&可以定义参数.因此,即使没有(直接)依赖项,构建脚本的附加层"也将经常发生.

这是一个优点,因为在构建过程中仍然存在更多模块化方法的空间.另一方面,如果要在另一个不相关的解决方案中重用项目,则需要编写一个不同的定义文件. (另一方面,如公约1所述,如果整个解决方案只有一个构建文件,则需要一个不同的构建脚本.)至于维护要求,这是(IMO)高度依赖项目的.

我的想法倾向于公约2,但距离胜利还很遥远.实际上,您一直以来一直运作良好的公约1的经验可能是最大的优点:拥有一定组织经验的人员团队是宝贵的财富.

There seems to be two major conventions for organizing project files and then many variations.

Convention 1: High-level type directories, project sub-directories

For example, the wxWidgets project uses this style:

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

Pros:

  • If there are project dependencies, they can be managed from a single file
  • Flat build file structure

Cons:

  • Since test has its own header and cpp files, when you generate the unit test applications for EXE files rather than libraries, they need to include the object files from the application you are testing. This requires you to create inference rules and expand out relative paths for all the source files.
  • Reusing any of the projects in another solution requires you to extract the proper files out of the tree structure and modify any build scripts

Convention 2: High-level project directories, type sub-directories

For example, the Wireshark project uses this style

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

Pros:

  • Projects themselves are self-contained within their folders, making them easier to move and reuse
  • Allows for shorter inference rules in the build tools
  • Facilitates hierarchical build scripts

Cons:

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

We are currently using convention 1 on our project and so far it has worked fairly well. Now, I am in the process of adding unit testing (via CxxTest) and facilitating the migration to continuous integration using nmake, convention 1 is causing some serious headaches in the creation of the proper nmake files.

My primary requirements/goals are:

  • Reduce the level of effort to maintain the build scripts of the entire solution.

  • De-couple projects and their build steps within a solution from other projects.

  • Facilitate continuous integration via the use of build scripts for check-out to release media generation for each commit (obviously leveraging other tools such as CruiseControl as well).

  • Make adding or removing additional projects or source files as easy and least error-prone as possible for the developers.

So I ask:

  • Are there other pros and cons of either of these methods?
  • Is there a clear agrument that favors only one of these conventions?

解决方案

[A partial answer.]

In "Convention 2: High-level project dirs, type sub-directories," your single con is

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

That can also be viewed as a pro, in many projects.

If you have a lot of repetitive general definitions, one would probably want an include file for the build scripts, where solution-wide constants & parameters could be defined. So the "additional layer of build scripts" will frequently happen anyway, even if there are no (direct) dependencies.

It's a pro in that there's still room for a more modular approach in building. On the other hand, if you want to reuse a project in another, unrelated solution, you would need to compose a different definitions file. (On the other other hand, if there were a single build file for the whole solution, as in Convention 1, you would need a different build script.) As for your maintenance requirement, that's (IMO) very project-dependent.

My feeling leans towards Convention 2, but it's far from a clear win. In fact, your experience with Convention 1, which was working well until recently, may be the biggest pro of all: a team of people with experience with a certain organization is a valuable asset.

这篇关于如何使用nmake为C ++项目组织项目树?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆