组织项目文件似乎有两个主要约定，还有许多变体。
约定一：高级类型目录、项目子目录
例如wxWidgets 项目使用此样式：
/solution
/bin
/prj1
/prj2
/include
/prj1
/prj2
/lib
/prj1
/prj2
/src
/prj1
/prj2
/test
/prj1
/prj2
优点：
- 如果存在项目依赖项，可以从单个文件管理它们
- 扁平构建文件结构
缺点： >
- 由于 test 有自己的头文件和 cpp 文件，因此当您为 EXE 文件而不是库生成单元测试应用程序时，它们需要包含 来自您正在测试的应用程序的对象文件。 这需要您创建推理规则并展开所有源文件的相对路径。
- 在另一个解决方案中重用任何项目都需要您从树结构中提取适当的文件并修改任何构建脚本
约定 2：高级项目目录，键入子目录
例如，< a href="http://anonsvn.wireshark.org/wireshark/trunk/" rel="nofollow noreferrer">Wireshark 项目使用这种风格
/solution
/prj1
/bin
/include
/lib
/src
/test
/prj2
/bin
/include
/lib
/src
/test
优点：
- 项目本身是独立的在它们的文件夹中，使它们更容易移动和重用
- 允许构建工具中的推理规则更短 便于
- 分层构建脚本
缺点：
- 如果项目之间存在依赖关系，则需要在构建脚本之上添加一层额外的构建脚本用于管理构建顺序的项目目录
我们目前在我们的项目中使用约定 1，到目前为止它运行得相当好。 现在，我正在添加单元测试（通过 CxxTest）并使用 nmake，约定 1 在创建正确的 nmake 文件时引起了一些严重的麻烦。
我的主要要求/目标是：
所以我问：
- 还有其他优点和缺点吗？
这些方法中的任何一个？
- 是否有一个明确的观点只支持一方
这些约定？
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?
发布评论
评论（2）
[部分答案。]
在“约定 2：高级项目目录，类型子目录”中，您的唯一缺点是
在许多项目中，这也可以被视为专业人士。
如果您有很多重复的通用定义，则可能需要一个构建脚本的包含文件，其中包含解决方案范围的常量和定义。 可以定义参数。 因此，即使没有（直接）依赖关系，“构建脚本的附加层”无论如何都会经常发生。
这是一个优点，因为在构建中仍然有更多模块化方法的空间。 另一方面，如果您想在另一个不相关的解决方案中重用项目，则需要编写不同的定义文件。 （另一方面，如果整个解决方案只有一个构建文件，如约定 1 所示，您将需要不同的构建脚本。）至于您的维护要求，（IMO）非常依赖于项目。
我的感觉倾向于第二次公约，但距离明显的胜利还很远。 事实上，您在公约 1 方面的经验（直到最近一直运行良好）可能是最大的优点：具有特定组织经验的团队是一项宝贵的资产。
[A partial answer.]
In "Convention 2: High-level project dirs, type sub-directories," your single con is
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.
考虑使用 NTFS 连接点，以便您可以同时拥有两个组织。 快速定义：“连接点是 Microsoft 的符号链接实现，但它仅适用于目录。”
使用约定 2 作为“真实”布局，因为它使项目易于移动。 然后做出约定 1 的视图：
现在你已经
……这就是期望的结果。
如果您发现有益的话，您可以对 /src 或其他目录执行相同的操作。 受益于约定 1 视图的测试脚本位于 /solution/test 中。
Consider using NTFS junction points so you can have both organizations at once. Quick definition: "a junction point is Microsoft's implementation of symbolic links but it only works for directories."
Use Convention 2 for the "real" layout, because it makes the projects easy to move around. Then make a Convention 1 view:
Now you have ...
... which was the desired result.
You could do the same thing for /src or the other directories if you find it beneficial. Test scripts that benefit from a Convention 1 view live in /solution/test.