6 The |Gromacs| build system uses CMake (version
7 |CMAKE_MINIMUM_REQUIRED_VERSION| or newer is required) to generate the
8 actual build system for the build tool choosen by the user. See CMake
9 documentation for general introduction to CMake and how to use it. This
10 documentation focuses on how the |Gromacs| build system is organized and
11 implemented, and what features it provides to developers (some of which may be
12 of interest to advanced users).
14 Most developers use ``make`` or ``ninja`` as the underlying build system, so
15 there can be parts of the build system that are specifically designed for
16 command-line consumption with these tools, and may not work ideally with other
17 environments, but basic building should be possible with all the environments
20 Also, the build system and version control is designed for out-of-source
21 builds. In-source builds mostly work (there are a few custom targets that do
22 not), but no particular effort has been put to, e.g., having :file:`.gitignore`
23 files that exclude all the build outputs, or to have the ``clean`` target
24 remove all possible build outputs.
29 Build types is a CMake concept that provides overall control of how
30 the build tools are used on the given platform to produce executable
31 code. These can be set in CMake in various ways, including on a
32 command line such as ``cmake -DCMAKE_BUILD_TYPE=Debug``. |Gromacs|
33 supports the following standard CMake build types:
36 Fully optimized code intended for use in production simulation. This is the
40 Compiled code intended for use with debugging tools, with low optimization levels
41 and debug information for symbols.
44 As Release, but with debug information for symbol names, which can help debugging
45 issues that only emerge in optimized code.
48 As Release, but optimized to minimize the size of the resulting executable. This
49 is never a concern for |Gromacs| installations, so should not be used, but
52 Additionally, |Gromacs| provides the following build types for development and
53 testing. Their implementations can be found in ``cmake/gmxBuildTypeXXX.cmake``.
56 This build type compiles a version of |Gromacs| aimed solely at correctness. All
57 parallelization and optimization possibilities are disabled. This build type is
58 compiled with gcc 5 to generate the regression test reference values, against
59 which all other |Gromacs| builds are tested.
62 As Release, but removes ``-DNDEBUG`` from compiler command lines, which makes
63 all assertion statements active (and can have other safety-related side effects
64 in |Gromacs| and code upon which it depends)
67 As Release, but adds ``-pg`` for use with profiling tools. This is not
68 likely to be effective for profiling the performance of :ref:`gmx mdrun`, but can
69 be useful for the tools.
72 Builds |Gromacs| for use with ThreadSanitzer in gcc and clang
73 (http://clang.llvm.org/docs/ThreadSanitizer.html) to detect
74 data races. This disables the use of atomics in ThreadMPI,
75 preferring the mutex-based implementation.
78 Builds |Gromacs| for use with AddressSanitzer in gcc and
79 clang (http://clang.llvm.org/docs/AddressSanitizer.html) to
80 detect many kinds of memory mis-use. By default, AddressSanitizer
81 includes LeakSanitizer.
84 Builds |Gromacs| for use with AddressSanitzer in clang
85 (http://clang.llvm.org/docs/MemorySanitizer.html) to detect
86 reads of unitialized memory. This functionality requires that
87 dependencies of the |Gromacs| build have been built in a compatible
88 way (roughly, static libraries with ``-g -fsanitize=memory
89 -fno-omit-frame-pointer``), which generally requires at least the C++
90 standard library to have been built specially. The path where the
91 includes and libraries for dependencies should be found for this
92 build type is set in the CMake cache variable
93 ``GMX_MSAN_PATH``. Only internal XDR and internal fftpack are
94 supported at this time.
96 For all of the sanitizer builds, to get readable stack traces, you may
97 need to ensure that the ``ASAN_SYMBOLIZER_PATH`` environment variable
98 (or your ``PATH``) include that of the ``llvm-symbolizer`` binary.
100 With some generators, CMake generates the build system for more than a
101 single ``CMAKE_BUILD_TYPE`` from one pass over the ``CMakeLists.txt``
102 files, so any code that uses ``CMAKE_BUILD_TYPE`` in
103 ``CMakeLists.txt`` directly will break. |Gromacs| does use such CMake
104 code, so we do not fully support all these build types in such
105 generators (which includes Visual Studio).
107 CMake cache variables
108 ---------------------
110 This section provides a (currently incomplete) list of cache variables that
111 developers or advanced users can set to affect what CMake generates and/or what
116 Figure out where to document basic variables intended for user
117 consumption, and how does it relate to documentation here.
121 Document the remaining variables below, and identify any variables
122 missing from the list.
127 Standard CMake mechanism for specifying the compiler flags is to use
128 ``CMAKE_C_FLAGS``/``CMAKE_CXX_FLAGS`` for flags that affect all build types,
129 and :samp:`CMAKE_C_FLAGS_{buildtype}`/:samp:`CMAKE_CXX_FLAGS_{buildtype}` for
130 flags that only affect a specific build type. CMake provides some default flags.
132 |Gromacs| determines its own set of default flags, grouped into two categories:
134 * Generic flags that are appended to the above default CMake flag variables
135 (possibly for multiple build types), generally specifying optimization flags
136 to use and controlling compiler warnings.
137 * Specific flags for certain features that the build system determines to be
138 necessary for successful compilation. One example is flags that determine
139 what SIMD instruction set the compiler is allowed to use/needs to support.
141 All of the above flags are only added after testing that they work with the
144 There is one cache variable to control the behavior of automatic compiler flags:
146 .. cmake:: GMX_SKIP_DEFAULT_CFLAGS
148 If set ``ON``, the build system will not add any compiler flags
149 automatically (neither generic nor specific as defined above), and will skip
150 most linker flags as well.
151 The default flags that would have been added are instead printed out when
152 :command:`cmake` is run, and the user can set the flags themselves using the
154 If ``OFF`` (the default), the flags are added as described above.
156 The code the determine the default generic flags is in
157 :file:`cmake/gmxCFlags.cmake`.
158 Code that sets the specific flags (e.g., SIMD flags) is in the main
159 :file:`CMakeLists.txt`; search for :cmake:`GMX_SKIP_DEFAULT_CFLAGS`.
160 The variables used there can be traced back to the locations where the actual
161 flags to use are determined.
163 Variables affecting compilation/linking
164 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
166 .. cmake:: GMX_BROKEN_CALLOC
168 .. cmake:: GMX_BUILD_FOR_COVERAGE
170 Special variable set ``ON`` by Jenkins when doing a build for the coverage
171 job. Allows the build system to set options to produce as useful coverage
172 metrics as possible. Currently, it disables all asserts to avoid them
173 showing up as poor conditional coverage.
174 Defaults to ``OFF``, and there should not be any need to change this in a
177 .. todo:: This could likely be replaced by a (yet another) build type.
179 .. cmake:: GMX_BUILD_MDRUN_ONLY
181 If set ``ON``, the build system is configured to only build and install a
182 single :file:`mdrun` executable. To be fully functional, the installed
183 :file:`mdrun` requires a standard |Gromacs| installation (with
184 ``GMX_BUILD_MDRUN_ONLY=OFF``) in the same installation prefix, as the
185 mdrun-only build does not install any data files or scripts, only the
186 binary. This is intended for cases where one wants to/needs to compile one
187 or more instances of :file:`mdrun` with different build options (e.g., MPI
188 or SIMD) than the full installation with the other utilities.
189 Defaults to ``OFF``, in which case a single :file:`gmx` executable is built
190 and installed, together with all the supporting files. :command:`mdrun` can
191 be executed as :command:`gmx mdrun`.
193 .. cmake:: GMX_BUILD_OWN_FFTW
195 .. cmake:: GMX_BUILD_SHARED_EXE
197 .. cmake:: GMX_COMPILER_WARNINGS
199 If set ``ON``, various compiler warnings are enabled for compilers that
200 Jenkins uses for verification.
201 Defaults to ``OFF`` when building from a source tarball so that users
202 compiling with versions not tested on Jenkins are not exposed to our rather
203 aggressive warning flags that can trigger a lot of warnings with, e.g., new
204 versions of the compilers we use.
205 When building from a git repository, defaults to ``ON``.
207 .. cmake:: GMX_CYCLE_SUBCOUNTERS
209 If set to ``ON``, enables performance subcounters that offer more
210 fine-grained mdrun performance measurement and evaluation than the default
211 counters. See :doc:`/user-guide/mdrun-performance` for the description of
212 subcounters which are available.
215 .. cmake:: GMX_ENABLE_CCACHE
217 If set to ``ON``, attempts to set up the `ccache <https://ccache.samba.org>`_
218 caching compiler wrapper to speed up repeated builds.
219 The ``ccache`` executable is searched for with ``find_package()`` if CMake
220 is being run with a compatible build type.
221 If the executable is found and a compatible compiler is configured,
222 CMake launch wrapper scripts are set.
223 If enabled, the ``ccache`` executable location discovered by CMake must be
224 accessible during build, as well.
225 Defaults to ``OFF`` to minimize build system complexity.
227 .. cmake:: GMX_INSTALL_DATASUBDIR
229 Sets the subdirectory under CMAKE_INSTALL_DATADIR where GROMACS-specific
230 read-only architecture-independent data files are installed. The default
231 is ``gromacs``, which means the files will go under ``share/gromacs``.
232 To alter the ``share`` part, change CMAKE_INSTALL_DATADIR.
233 See :doc:`relocatable-binaries` for how this influences the build.
235 .. cmake:: GMX_DOUBLE
237 Many part of |Gromacs| are implemented in terms of "real" precision,
238 which is actually either a single- or double-precision type,
239 according to the value of this flag. Some parts of the code
240 deliberately use single- or double-precision types, and these are
241 unaffected by this setting. See reference manual for further
244 .. cmake:: GMX_RELAXED_DOUBLE_PRECISION
246 Permit a double-precision configuration to compute some quantities
247 to single-precision accuracy. Particularly on architectures where
248 only double-precision SIMD is available (e.g. Sparc machines such
249 as the K computer), it is faster to default to ``GMX_DOUBLE=ON``
250 and use SIMD than to use ``GMX_DOUBLE=OFF`` and use no
251 SIMD. However, if the user does not need full double precision,
252 then some optimizations can achieve the equivalent of
253 single-precision results (e.g. fewer Newton-Raphson iterations for
254 a reciprocal square root computation).
256 .. cmake:: GMX_EXTRAE
258 .. cmake:: GMX_EXTERNAL_BLAS
260 .. cmake:: GMX_EXTERNAL_LAPACK
262 .. cmake:: GMX_EXTERNAL_TNG
264 .. cmake:: GMX_FFT_LIBRARY
266 .. cmake:: GMX_GIT_VERSION_INFO
268 Whether to generate version information dynamically from git for each build
269 (e.g., HEAD commit hash).
270 Defaults to ``ON`` if the build is from a git repository and :command:`git`
271 is found, otherwise ``OFF``.
272 If ``OFF``, static version information from
273 :file:`cmake/gmxVersionInfo.cmake` is used.
277 .. cmake:: GMX_CLANG_CUDA
279 Use clang for compiling CUDA GPU code, both host and device.
281 .. cmake:: GMX_CUDA_CLANG_FLAGS
283 Pass additional CUDA-only compiler flags to clang using this variable.
285 .. cmake:: CMAKE_INSTALL_LIBDIR
287 Sets the installation directory for libraries (default is determined by
288 standard CMake package ``GNUInstallDirs``).
289 See :doc:`relocatable-binaries` for how this influences the build.
291 .. cmake:: GMX_LOAD_PLUGINS
295 .. cmake:: GMX_OPENMP
297 .. cmake:: GMX_PREFER_STATIC_LIBS
301 .. cmake:: GMX_SOFTWARE_INVSQRT
303 .. cmake:: GMX_THREAD_MPI
305 .. cmake:: GMX_USE_RDTSCP
307 .. cmake:: GMX_USE_TNG
309 .. cmake:: GMX_VMD_PLUGIN_PATH
315 Currently, this option has no effect on the compilation or linking, since
316 there is no code outside the tests that would use :file:`libxml2`.
318 Variables affecting the ``all`` target
319 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
321 .. cmake:: BUILD_TESTING
323 Standard variable created by CTest that enables/disables all tests.
326 .. cmake:: GMX_BUILD_HELP
328 Controls handling of man pages and shell completions. Possible values:
330 ``OFF`` (default for builds from release source distribution)
331 Man pages and shell completions are not generated as part of the ``all``
332 target, and only installed if compiling from a source package.
333 ``AUTO`` (default for builds from development version)
334 Shell completions are generated by executing the :file:`gmx` binary as
335 part of the ``all`` target. If it fails, a message is printed, but the
337 Man pages need to be generated manually by invoking the ``man`` target.
338 Man pages and shell completions are installed if they have been
339 successfully generated.
341 Works the same as ``AUTO``, except that if invoking the :file:`gmx` binary
342 fails, the build fails as well.
344 .. cmake:: GMX_DEVELOPER_BUILD
346 If set ``ON``, the ``all`` target will include also the test binaries using
347 Google Test (if :cmake:`GMX_BUILD_UNITTESTS` is ``ON``).
348 Also, :cmake:`GMX_COMPILER_WARNINGS` is always enabled.
349 In the future, other developer convenience features (as well as features
350 inconvenient for a general user) can be added to the set controlled by this
353 .. cmake:: GMX_CLANG_TIDY
355 `clang-tidy <http://releases.llvm.org/8.0.0/tools/clang/tools/extra/docs/clang-tidy/index.html>`_
356 is used for static code analysis and (some) automated fixing of issues detected. clang-tidy is easy to install. It is contained in
357 the llvm binary `package <http://releases.llvm.org/download.html#8.0.0>`_. Only
358 version 8.0.* with libstdc++<7 or libc++ is supported. Others might miss tests or give false positives.
359 It is run automatically on Jenkins for each commit. Many checks have fixes which can automatically be
360 applied. To run it, the build has to be configured with
361 ``cmake -DGMX_CLANG_TIDY=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=on``.
362 Any ``CMAKE_BUILD_TYPE`` which enables asserts (e.g. ASAN) works. Such a configured build will
363 run both the compiler as well as clang-tidy when building. The name of the clang-tidy executable is set with
364 ``-DCLANG_TIDY=...``, and the full path to it can be set with ``-DCLANG_TIDY_EXE=...``.
365 To apply the automatic fixes to the issue identified clang-tidy should be run seperately (running clang-tidy
366 with ``-fix-errors`` as part of the build can corrupt header files). To fix a specific file run
367 ``clang-tidy -fix-errors -header-filter '.*' {file}``, to fix all files in parallel
368 ``run-clang-tidy.py -fix -header-filter '.*' '(?<!/selection/parser\.cpp|selection/scanner\.cpp)$'``,
369 and to fix all modified files ``run-clang-tidy.py -fix -header-filter '.*' $(git diff HEAD --name-only)``.
370 The run-clang-tidy.py script is in the
371 ``share/clang/`` subfolder of the llvm distribution. ``clang-tidy`` has to be able to find the
372 ``compile_commands.json`` file. Either run from the build folder or add a symlink to the source folder.
373 :cmake:`GMX_ENABLE_CCACHE` does not work with clang-tidy.
375 Variables affecting special targets
376 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
380 If set ``ON``, the additional ``gmxapi`` C++ library is configured and the
381 ``gmxapi`` headers will be installed. Provides the additional build tree
382 targets ``gmxapi-cppdocs`` and ``gmxapi-cppdocs-dev`` when Doxygen is
383 available. Also exports CMake configuration files for ``gmxapi`` that allow
384 ``find_package(gmxapi)`` to import the ``Gromacs::gmxapi`` CMake target in
385 client projects that search the GROMACS installation root.
387 .. cmake:: GMX_BUILD_MANUAL
389 If set ``ON``, CMake detection for LaTeX and other prerequisites for the
390 reference PDF manual is done, and the ``manual`` target for building the
392 If ``OFF`` (the default), all detection is skipped and the manual cannot be
395 .. todo:: Consider if this is really necessary, or if we could just use
398 .. cmake:: GMX_BUILD_TARBALL
400 If set ``ON``, ``-dev`` suffix is stripped off from version strings and some
401 other version info logic is adjusted such that the man pages and other
402 documentation generated from this build is suitable for releasing (on the
403 web page and/or in the source distribution package).
406 .. cmake:: GMX_BUILD_UNITTESTS
408 If ``ON``, test binaries using Google Test are built (either as the separate
409 ``tests`` targer, or also as part of the ``all`` target, depending on
410 :cmake:`GMX_DEVELOPER_BUILD`). All dependencies required for building the
411 tests (Google Test and Google Mock frameworks, and tinyxml2) are
412 included in :file:`src/external/`.
413 Defaults to ``ON`` if :cmake:`BUILD_TESTING` is ``ON``.
415 .. cmake:: GMX_COMPACT_DOXYGEN
417 If set ``ON``, Doxygen configuration is changed to avoid generating large
418 dependency graphs, which makes it significantly faster to run Doxygen and
419 reduces disk usage. This is typically useful when developing the
420 documentation to reduce the build times.
423 .. cmake:: REGRESSIONTEST_DOWNLOAD
425 If set ``ON``, CMake will download the regression tests and extract them to
426 a local directory. :cmake:`REGRESSIONTEST_PATH` is set to the extracted
427 tests. Note that this happens during the configure phase, not during the
429 After the download is done, the variable is automatically reset to ``OFF``
430 again to avoid repeated downloads. Can be set to ``ON`` to download again.
433 .. cmake:: REGRESSIONTEST_PATH
435 Path to extracted regression test suite matching the source tree (the
436 directory containing :file:`gmxtest.pl`)
437 If set, CTest tests are generated to run the regression tests.
440 .. cmake:: SOURCE_MD5SUM
442 Sets the MD5 sum of the release tarball when generating the HTML
443 documentation. It gets inserted into the download section of the HTML
451 List external libraries used (either from src/external/, or from the
452 system), whether they are required or optional, what functionality they
453 provide for Gromacs, and how to control their use.
458 In addition to the default ``all`` target, the generated build system has
459 several custom targets that are intended to be explicitly built to perform
460 various tasks (some of these may also run automatically). There are various
461 other targets as well used internally by these, but those are typically not
462 intended to be invoked directly.
465 Builds all the binaries needed by the tests and runs the tests. If some
466 types of tests are not available, shows a note to the user.
467 This is the main target intended for normal users to run the tests.
468 See :doc:`testutils`.
470 Runs a custom Python checker script to check for various source-level
471 issues. Uses Doxygen XML documentation as well as rudimentary parsing of
472 some parts of the source files.
473 This target is used as part of the Jenkins documentation job.
474 All CMake code is currently in :file:`docs/doxygen/`.
477 Runs the compiled :file:`gmx` executable to generate shell command-line
478 completion definitions. This target is only added if
479 :cmake:`GMX_BUILD_HELP` is not ``OFF``, and it is run automatically as part
480 of the default ``all`` target. See :cmake:`GMX_BUILD_HELP`.
481 All CMake code is in :file:`src/programs/`.
483 Builds include dependency graphs for the source files using :command:`dot`
485 All CMake code is in :file:`docs/doxygen/`.
488 Targets that run Doxygen to generate the documentation.
489 The ``doxygen-all`` target runs as part of the ``webpage`` target, which in
490 turn runs as part of the Jenkins documentation job.
491 All CMake code is in :file:`docs/doxygen/`.
494 Builds API documentation for gmxapi. Useful to authors of client software.
495 Documentation is generated in :file:`docs/api-user` in the build directory.
497 Extract documentation for gmxapi and GROMACS developers to
498 :file:`docs/api-dev`.
500 Runs Sphinx to generate a plain-text INSTALL file for the source package.
501 The files is generated at :file:`docs/install-guide/text/`, from where it
502 gets put at the root of the source package by CPack.
503 All CMake code is in :file:`docs/`.
505 Runs Sphinx to generate man pages for the programs.
506 Internally, also runs the compiled :file:`gmx` executable to generate the
507 input files for Sphinx.
508 All CMake code is in :file:`docs/`.
509 See :cmake:`GMX_BUILD_HELP` for information on when the man pages are
512 Runs LaTeX to generate the reference PDF manual.
513 All CMake code is in :file:`docs/manual/`.
514 See :cmake:`GMX_BUILD_MANUAL`.
516 Standard target created by CPack that builds a source package.
517 This target is used to generate the released source packages.
519 Standard target created by CTest that runs all the registered tests.
520 Note that this does not build the test binaries, only runs them, so you need
521 to first ensure that they are up-to-date.
522 See :doc:`testutils`.
524 Builds all the binaries needed by the tests (but not ``gmx``).
525 See :doc:`testutils`.
527 Collection target that runs the other documentation targets to generate the
528 full set of HTML (and linked) documentaion.
529 This target is used as part of the Jenkins documentation job.
530 All CMake code is in :file:`docs/`.
532 Runs Sphinx to generate most content for the HTML documentation (the set of
533 web pages this developer guide is also part of).
534 Internally, also runs the compiled :file:`gmx` executable to generate some
535 input files for Sphinx.
536 All CMake code is in :file:`docs/`.
538 Passing information to source code
539 ----------------------------------
541 The build system uses a few different mechanisms to influence the compilation:
543 * On the highest level, some CMake options select what files will be compiled.
544 * Some options are passed on the compiler command line using ``-D`` or
545 equivalent, such that they are available in every compilation unit. This
546 should be used with care to keep the compiler command lines manageable.
547 You can find the current set of such defines with ::
549 git grep add_definitions
551 * A few header files are generated using CMake ``configure_file()`` and
552 included in the desired source files. These files must exist for the
553 compilation to pass. Only a few files use an ``#ifdef HAVE_CONFIG_H`` to
554 protect against inclusion in case the define is not set; this is used in
555 files that may get compiled outside the main build system.
558 Contains various strings about the build environment, used mainly for
559 outputting version information to log files and when requested.
561 Contains defines for conditional compilation within source files.
562 :file:`gmxpre-config.h`
563 Included by :file:`gmxpre.h` as the first thing in every source file.
564 Should only contain defines that are required before any other header for
565 correct operation. For example, defines that affect the behavior of system
566 headers fall in this category. See Doxygen documentation for
569 All the above files get generated in :file:`src/`.
571 Additionally, the following file is generated by the build system:
573 :file:`baseversion-gen.cpp`
574 Provides definitions for declarations in :file:`baseversion_gen.h` for
575 version info output. The contents are generated either from Git version
576 info, or from static version info if not building from a git repository.