如何使用nmake为C ++项目组织项目树?

我的想法倾向于公约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-directoriesFor example, the wxWidgets project uses this style:/solution /bin /prj1 /prj2 /include /prj1 /prj2 /lib /prj1 /prj2 /src /prj1 /prj2 /test /prj1 /prj2Pros:If there are project dependencies, they can be managed from a single fileFlat build file structureCons: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 scriptsConvention 2: High-level project directories, type sub-directoriesFor example, the Wireshark project uses this style/solution /prj1 /bin /include /lib /src /test /prj2 /bin /include /lib /src /testPros:Projects themselves are self-contained within their folders, making them easier to move and reuseAllows for shorter inference rules in the build toolsFacilitates hierarchical build scriptsCons:If there are dependencies between projects, you need an additional layer of build scripts above the project directories to manage the build orderWe 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 ofeither of these methods?Is there a clear agrument that favors only oneof 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 orderThat 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 ++项目组织项目树?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！