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 it's own header and cpp files, when you generate the unit test applications for EXEs rather than libraries, they need to include the obj 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 dirs, 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 currently are 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?