Skip to content

CMake Compilation works without changing source files

Riccardo Rehorequested to merge
riccardoreho95/lumen:tech-cmake into tech-cmake

This merge request introduces an initial implementation of CMake support for building the lumen codebase. The goal is to offer a modern and modular alternative to the traditional autotools build system, while preserving backward compatibility.

Instructions are available in the documentation file: compile_cmake.md.

Key changes

  • Added a full CMake-based build system with support for yambo, ypp, a2y, and other binaries.
  • Source files have been renamed from .F to .F90 to be consistent between formatting and naming, but their contents remain unchanged. Those changes could already be merged in develop. I did make a minor change in have_malloc.h.in, which I am not sure should be retained.
  • Multiple CMakeLists.txt files have been added to handle different parts of the project (src/, lib/, yambo/, etc.).
  • A dedicated config/cmake directory contains custom CMake functions.
  • Auxiliary python helper scripts are in the scripts/ folder.
  • A preprocess_fortran CMake function simulates the original preprocessor logic from bash-based Makefiles.

Project structure

  • Each executable (e.g. yambo, ypp, a2y) lives in its own folder with a dedicated CMakeLists.txt.
  • The source organization in lib/ and src/ is retained, but now governed by their own CMakeLists.txt files.
  • File lists to be compiled, for each module, are currently hard-coded based on .objects or .dep files. Exception : lib/qe_pseudo uses a dynamic mechanism to generate the source list by parsing .dep files with a custom CMake + Python utility. A similar automatic parsing for all the executable objects would be optimal.
  • Preprocessing of .F90 files is performed as a first step using the preprocess_fortran macro.

Libraries

  • CMake is not responsible for compiling external libraries such as NetCDF, MPI, etc.
  • These libraries should be compiled independently (typically via ./configure && make).
  • CMake will look for precompiled versions in user-specified paths.
  • Internal libraries in lib/ that contain Fortran code (e.g. qe_pseudo) are compiled via CMake.

Special cases:

  • Libraries such as ldiago, devxlib, etc., are treated separately. They can be compiled like qe_pseudo, or be fully integrated in the source tree.

They can be compiled like qe_pseudo, or be fully integrated in the source tree.

Known Limitations and WIP:

  • The current implementation is minimal and experimental.
  • Library auto-detection and linking are not guaranteed to work reliably across systems.
  • Users are encouraged to specify paths explicitly.
  • The build directory currently includes some redundant or unclear artifacts created by cmake. Those files can be imprvoed with a better architecture for the CMake compilation project. The final build structure still needs refinement. -The .objects → file list handling is not yet fully automated.

Next steps

  • Improve automation of file list generation using .dep or .objects files.
  • Clean and structure the output of the build/ directory.
  • Improve robustness of library detection and linking (possibly using Find*.cmake modules).
  • Rename scripts/ to something more descriptive, such as tools/ or utils/.
  • Document all procedures and conventions in compile_cmake.md.

Help

This feature is a work-in-progress and requires community collaboration. Contributions, testing on diverse systems, and feedback are highly welcome.

Please help improve:

  • Compatibility with other platforms
  • Integration with external tools (such as SPACK)
  • Handling of corner cases in preprocessing, file selection, and linking

Merge request reports