Library/Software Engineering/Project Structure

A Build Setup
The first step is to get a build setup together so you can focus on software development not software build engineering. The idea is to get a good, flexible setup in place from the start so that it "just works" as your project gets larger and more complex. Going back to re-organize a build after it is complex can be time-consuming process.

The tutorial uses CMake as it is simple, cross-platform, allows hierarchical inheritance of build settings, etc. However, the tutorial will try to be as generic as possible.

Top-Level Project Layout
The approach taken here is to look at very large, complex project that may be composed of multiple target executables, tools, and both internal and external source libraries. By starting with a project layout capable of handling all that complexity, unnecessary parts can be stripped away - but as the project expands, new targets and dependencies will have a logic place in the build tree structure.


 * project_name
 * build - CMake build directory
 * dev - source repository directory
 * apps - executables built within the project
 * libs - general static and dynamic libraries
 * plugins - dynamic libraries specific to the project
 * config - build configuration files
 * docs - API and user documentation
 * media - resource files
 * benchmarks - automated performance tests
 * unittest - automated correctness tests
 * samples - user samples
 * sandbox - internal work-in-progress samples, demos, and tests
 * dependencies - pre-compiled dependencies
 * external - third-party source code compiled within the build
 * tools - internal tools for the build
 * contrib - misc. non-essential, but useful files

Sub-projects Layout
Within any particular build-able subdirectory (e.g. app, lib, sample), the layout should include src and include directories.


 * libs
 * lib_name
 * include
 * lib_name
 * header1.hpp, ...
 * src
 * module1
 * sourceABC.cpp, ..
 * module2
 * sourceXYZ.cpp, ...
 * maincode.cpp, ...

Additionally, any sub-project specific benchmarks, unittests, etc. should be included within that sub-project.


 * libs
 * lib_name
 * include
 * src
 * benchmarks
 * unittest
 * samples

Types of Files
Here the broad types of files being considered


 * Applications
 * Core Engine DLLs
 * Plug-in DLLs
 * Samples
 * Unit Tests / Benchmarks
 * Documentation
 * Shared Data files
 * Unshared Data file
 * SDK