Skip to content

CMake support

Federico Ficarelli requested to merge nazavode/q-e:develop into develop

This PR adds tentative support for build system generation via Modern CMake.

Please note that this is currently WIP: as previously discussed with a bunch of QE maintainers (pinging @pietrodelugas and @carcava), the goal here is to add CMake scripts for a minimal subset of QE modules first and then iterate with a larger audience of QE maintainers to address specific issues or use cases. Reviews are more than welcome!

At this stage, this PR addresses LAXLib only, including all of its direct and transitive dependencies. The dependency graph looks like this:


Getting started

In order to build all the targets provided by QE, an out of source build can be performed like this:

$ mkdir build
$ cd build
$ cmake <path to qe repo>
$ make

Build options

At this stage, only the build options that make sense for LAXLib are provided. In order to inspect them, including their values for the current build, just do:

$ cd <qe repo>
$ cd build
$ cmake -LH
-- Cache values
// Choose the type of build.

// Install path prefix, prepended onto install directories.

// enable global synchronization between execution units

// enable distributed execution support via MPI

// enable inplace MPI calls (ignored when QE_ENABLE_MPI=OFF)

// use MPI via Fortran module instead of mpif.h header inclusion

// enable unit tests

// enable execution tracing output

// enable fallback on vendored deps when none is found via find_package()

In order to set a specific option's value you can ask the cmake command; e.g.: to enable building unit tests:

$ cd <qe repo>
$ cd build
$ cmake -DQE_ENABLE_TEST=ON ..
$ make test

Notes on external dependencies

While for some dependencies (e.g.: MPI) the only sensible way is to look for a suitable implementation provided by the build environment, for others we can do a bit more. Just consider LAPACK for instance: right now QE is able to download the reference netlib implementation when the build system is unable to find a suitable LAPACK, a process usually known as vendoring. This PR follows the same approach with some notable changes:

  1. All vendored dependencies and support scripts are placed inside the <repo>/external directory
  2. All vendored dependencies are pinned to a specific git remote and commit hash via a proper git submodule; for LAPACK we have:
    $ git submodule status
    12d825396fcef1e0a1b27be9f119f9e554621e55 external/lapack (v3.7.0-492-g12d82539)
    The specific remote the submodule is pointing to is specified in the .gitmodules configuration file:
    $ cat .gitmodules
    [submodule "external/lapack"]
        path = external/lapack
        url =
  3. When the CMake generation process cannot find a suitable dependency, the relative submodule is automatically downloaded and the source tree is added via add_subdirectory(): this enables direct import of any CMake target defined by the dependency's own CMakeLists.txt.
  4. it's possible to disable dependencies vendoring at all by switching off the corresponding build option:
Edited by Federico Ficarelli

Merge request reports