17

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

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

例如，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）。

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

所以我问：

  • 这两种方法还有其他优点和缺点吗？
  • 是否有明确的规定只支持其中一种约定？
4

2 回答 2

4

[部分答案。]

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

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

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

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

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

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

于 2008-11-06T07:53:28.317 回答
1

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

对“真实”布局使用约定 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 中。

于 2008-11-06T12:23:18.117 回答