Build system internals

This page provides details about the CMake build system. Files processed by the top level CMakeLists.txt script are listed in the TOC in chronological order.

  1. Coding convention
  2. Configuration
    1. ./CMakeLists.txt and ./cmake/setup_*.cmake
    2. ./cmake/checks/check_*.cmake
    3. ./cmake/modules/Find*.cmake
    4. ./cmake/configure/configure_*.cmake
    5. Global variables controlling the build process
  3. Target definition and installation
    1. ./include/deal.II/base/
    2. ./source/CMakeLists.txt
    3. ./cmake/config/CMakeLists.txt

Coding convention

Coding conventions are always a matter of choice. Nevertheless, the following rules should be considered:

An example:
  # Set an appropriate keyword depending on target and build type:
    SET(_keyword "general")
    IF(_build MATCHES DEBUG)
      SET(_keyword "debug")
      SET(_keyword "optimized")


CMake operates almost always with variables in global state. To guard against accidental overwrite of variables the following naming conventions must be followed at all times:


./CMakeLists.txt and ./cmake/setup_*.cmake

The very first configuration steps after some initial setup in ./CMakeLists.txt takes place in some ./cmake/setup_*.cmake files:


The next step in the configuration process is to include all checks residing under ./cmake/checks. Currently there are:

  - Search for support for compiler dependent features such as stack
    trace support, demangler support, etc.

  - Platform introspection for CPU features goes here and must be

  - Check for supported C++ language features such as sufficient C++11

  - Checks for specific platform (Linux/Darwin/CYGWIN/Windows..)
    features and support

  - Check for compiler bugs


These are find modules for the configure_*.cmake files and the CONFIGURE_FEATURE macro as will explained later. It is crucial that a find module behaves correctly. Therefore, the following rules are mandatory:


The final step in the configuration phase is the setup of features (which refer to external or bundled libraries deal.II can optionally interface with.)

At bare minimum configure_<feature>.cmake file for a feature just consists of a call to the CONFIGURE_FEATURE(<FEATURE>) macro which is implemented in ./cmake/macros/macro_configure_feature.cmake. In this case the corresponding Find<FEATURE>.cmake module is used to determine whether an external dependency can be resolved or not. Depending on the current state of DEAL_II_WITH_<FEATURE> (see here) the configuration variables

are appended to the set of global variables and DEAL_II_WITH_<FEATURE> is set to TRUE.

It is possible to override this default behaviour with the following variables and macros (all of them are optional and will be replaced by an appropriate default action if unset):

Global variables controlling the build process

The following list describes all global variables controlling the build process and the visibility associated with it (internal use for compiling deal.Ii, externally used variables will get exported in deal.IIConfig.cmake). Lists should be manipulated with LIST(APPEND ...), flags with ADD_FLAGS(...) (or if it is necessary to guard them with ENABLE_IF_SUPPORTED(...).)

Feature configuration must not be added directly to this variables but to corresponding <FEATURE>_* variables, instead. Feature configuration variables get appended to the below list of global configuration variables automatically.

Target definition and installation


In contrast to autoconf there is no intermediate step any more that automatically generates The setup in this file has to be done by hand. Please note:


All parts of the library are organized into logical object libraries with their respective sources lying under ./source/<foo>, or ./bundled/<foo>/<...>. The actual setup of an object library happens within that subdirectories with the help of two macros:

# Glob for all header files associated with the object target:
# As this list is only for cosmetic reasons, so that associated header
# files show up in IDEs, we don't manage an explicit list (with the
# trade-off to have to run "make rebuild_cache" when a new header file
# emerges...)
FILE(GLOB _header

# A list of source files forming the object target:

# A list of instantiations that must be expanded:

# The following macro will set up an obj_dofs.debug and
# obj_dofs.release target  with appropriate compile flags and
# definitions for a simultaneous build of debug and release library.
# Furthermore, the object name will be stored in
#   ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/deal_ii_objects_(debug/release)
# so that it is available in global scope.
# Header files and instantiation files (${_header}, ${_inst}) are added
# for cosmetic reasons, so that they show up in IDEs.
DEAL_II_ADD_LIBRARY(obj_dofs OBJECT ${_src} ${_header} ${_inst})

# This macro will set up an obj_dofs.inst target for expanding all
# files listed in ${inst_in_files}. Appropriate target dependencies
# will be added to obj_dofs.debug and obj_dofs.release.
EXPAND_INSTANTIATIONS(obj_dofs "${inst_in_files}")

Later, all object targets are collected in ./source/CMakeLists.txt to define the actual debug and releases libraries. For further details, see ./source/CMakelists.txt and ./cmake/macros/macro_deal_ii_add_library.cmake.


The final bits of configuration happens in ./cmake/config/CMakeLists.txt where the templates for the project configuration deal.IIConfig.cmake gets expanded. Furthermore, the configuration for the template expansion mechanism resides under ./cmake/config/

Valid HTML 4.01! Valid CSS!