CMake build system

I wasn't quite sure where to go with this, and this seemed to be the best place I could think of so I thought why not. I threw together a build system for C++ projects today using CMake and I wanted your opinions on it, on things I could do better, or change to better comply with best practices.

Here's my directory structure:

.
├── bin (Compiled executables)
│   └── lib (Executables from third-party libraries)
├── build (The CMake build folder)
│   ├── CMakeCache.txt
│   ├── CMakeFiles
│   ├── cmake_install.cmake
│   ├── inc
│   ├── lib
│   ├── Makefile
│   └── test
├── CMakeLists.txt
├── inc (Objects used in programming)
│   └── CMakeLists.txt
| └── fake_object (An example)
| └── fake_object.h
| └── fake_object.cc
├── lib (External/third-party libraries)
│   ├── CMakeLists.txt
│   └── gmock (Unit testing)
├── main.cc
├── res (External resources such as images, sounds, fonts)
└── test (tests, lol)
└── CMakeLists.txt


I decided to take a modular approach to my C++ structure, so each object I build for my programs has its own directory within the inc folder.

Here is my main CMakeLists.txt:

`########################################################################
# Basic info #
########################################################################

cmake_minimum_required(VERSION 2.8)
project(skeleton)

########################################################################
# Variables #
########################################################################

# My vars
set(test_prefix ${CMAKE_SOURCE_DIR}/test)
set(GMOCK_DIR ${CMAKE_SOURCE_DIR}/lib/gmock)
set(GMOCK_TEST_LIBS ${CMAKE_SOURCE_DIR}/bin/lib)

# System vars
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin)
set(CMAKE_CXX_FLAGS -lpth

This generally looks pretty good, but I have a few suggestions that might allow you to make your code and build system a little better.

Replace inc with src

The source code for your projects is apparently going into inc. I would expect source code in src and header-only includes perhaps in inc. I'd suggest changing from inc to src to make it clear that it's all source code and not just include files in there.

Move your main.cc with the rest of the source code

There is no one place for source code with this system, which is unfortunate. For something like ctags which can recursively build references to parts of your code, it's convenient for all of the code to be in a particular place, or at least at the top of a hierarchical directory tree. This might be the top of a hierarchy, except that the build directory is also under it, so source files copied there would have to be explicitly excluded. For my projects, I find it easier to put the source in a single subdirectory named src.

Reconsider "one directory per object"

If your projects are anything like mine, I think you'll find that there is very little to be gained in having each object get its own subdirectory. I usually find it easier to put all of the source together in a single directory. Only major subsystems, rather than individual objects, get a subdirectory.

Add a source package target

Sharing with others via source repository is good, but sometimes it's handy to just create a tarball. For that, I'd recommend using CPack to create it. Here's what I use:

set(CPACK_PACKAGE_VERSION_MAJOR "0")
set(CPACK_PACKAGE_VERSION_MINOR "1")
set(CPACK_PACKAGE_VERSION_PATCH "1")
SET(CPACK_SOURCE_GENERATOR "TBZ2")
SET(CPACK_SOURCE_PACKAGE_FILE_NAME "${CPACK_PACKAGE_FILE_NAME}_Source.tar.gz")
SET(CPACK_SOURCE_IGNORE_FILES "/build/;/*.swp;.git*")
set(CPACK_SOURCE_PACKAGE_FILE_NAME
  "${CMAKE_PROJECT_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
include (CPack)

One significant use of this is that once you have a "standard tree" set up, you can create the source tarball and then whenever you start a new project, simply untar the scaffolding into place and then go in and edit just the few things that would need to be project specific.

Add a doc subdirectory

As you've mentioned, generating documentation via Doxygen is often handy. I typically have a doc subdirectory off the top level into which the source for documentation would go. That is, if man or user manual is generated, I put the sources in there. I also tend to put programmer notes in there if they aren't already part of the Doxygen output. Then the generated documents that result from all of that get put into the corresponding doc within the build tree.

Add a top-level README file

I usually put in a README file at the very top. One obvious thing to put into it would be exactly the directory tree structure that you put into your question, perhaps with a bit more explanation about what goes where and simple instructions for how to build the project.

StackExchange Code Review Q#98320, answer score: 3