StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POHow to organize the project tree for a C++ project using nmake?
text
Body
copied!<h2>There seems to be two major conventions for organizing project files and then many variations.</h2> <p><strong>Convention 1: High-level type directories, project sub-directories</strong></p> <p>For example, the <a href="http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/" rel="nofollow noreferrer">wxWidgets</a> project uses this style:</p> <pre><code>/solution /bin /prj1 /prj2 /include /prj1 /prj2 /lib /prj1 /prj2 /src /prj1 /prj2 /test /prj1 /prj2 </code></pre> <p><strong>Pros:</strong></p> <ul> <li>If there are project dependencies, they can be managed from a single file</li> <li>Flat build file structure</li> </ul> <p><strong>Cons:</strong></p> <ul> <li>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 <a href="https://en.wikipedia.org/wiki/Object_file" rel="nofollow noreferrer">object files</a> from the application you are testing. This requires you to create inference rules and expand out relative paths for all the source files.</li> <li>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</li> </ul> <p><strong>Convention 2: High-level project directories, type sub-directories</strong></p> <p>For example, the <a href="http://anonsvn.wireshark.org/wireshark/trunk/" rel="nofollow noreferrer">Wireshark</a> project uses this style</p> <pre><code>/solution /prj1 /bin /include /lib /src /test /prj2 /bin /include /lib /src /test </code></pre> <p><strong>Pros:</strong></p> <ul> <li>Projects themselves are self-contained within their folders, making them easier to move and reuse</li> <li>Allows for shorter inference rules in the build tools</li> <li>Facilitates hierarchical build scripts</li> </ul> <p><strong>Cons:</strong></p> <ul> <li>If there are dependencies between projects, you need an additional layer of build scripts above the project directories to manage the build order</li> </ul> <p>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 <a href="https://en.wikipedia.org/wiki/Make_%28software%29#Modern_versions" rel="nofollow noreferrer">nmake</a>, convention 1 is causing some serious headaches in the creation of the proper nmake files.</p> <h2>My primary requirements/goals are:</h2> <ul> <li><p>Reduce the level of effort to maintain the build scripts of the entire solution.</p></li> <li><p>De-couple projects and their build steps within a solution from other projects.</p></li> <li><p>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).</p></li> <li><p>Make adding or removing additional projects or source files as easy and least error-prone as possible for the developers.</p></li> </ul> <h2>So I ask:</h2> <ul> <li>Are there other pros and cons of either of these methods?</li> <li>Is there a clear agrument that favors only one of these conventions?</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload