Migrating build system to CMake

[edo01]

Hi everyone,

I'd like to start a discussion about adding a CMake build to JOREK. I have a working prototype in my fork, and I'd like gathering some feedback.

Current Makefile situation

• On a new machine, the first step is usually finding a close-enough Makefile.inc and editing it until things link.
• Dependency tracking relies on two Perl scripts (util/makedepend and util/obj_deps). They scan use and call statements to determine dependencies and object files per executable. This requires module and subroutine names to match filenames, and no two files in DIRS to share a basename. Useless to say that this is not standard.
• Builds happen in the source tree (.obj/, .mod/, .dep/), so only one configuration can exist at a time. Switching model or build type means rebuilding from scratch.
• MPI_VERSION is determined by writing, compiling, and running a small Fortran program, then parsing its output.
• Compiler detection relies on $(FC) --version | grep ..., while Intel version checks use the shell and bc.

None of this is broken and it has worked for years, and people familiar with it know how to use it. But it is custom and can be prone to bugs.

Why CMake

CMake is an open-source, cross-platform build system. It uses compiler-independent configuration files and generates native build files for Make or IDEs.

What's the advantage for us:

• CMake handles module dependencies, replacing util/makedepend. Building non-program sources into one static library also lets the linker determine what each executable needs, replacing util/obj_deps. Filename conventions would no longer be required.
• Standard dependency discovery. find_package can handle MPI, HDF5, and BLAS/LAPACK rather than hand-written link lines. MPI_VERSION comes from FindMPI. Paths are still needed for sparse solvers such as STRUMPACK, MUMPS, PaStiX, METIS, and PARMETIS.
• Debug, release builds, or different models, can coexist without rebuilding everything.
• Versioned machine configurations. Cluster configurations could be kept in only one place in the repository through CMakePresets.json. cmake --list-presets shows the available configurations, and presets can record the required module load command.
• CI, regression tests, and development tools become easier to integrate. CTest can be used to wire up regression tests and CI, while compile_commands.json improves support for code editors and language servers. This is part of a broader effort to modernise the codebase, simplify development, and align more closely with common software-engineering practices.
• It represents a fundation for future GPU work.
• CMake is widely used, so most students and newcomers will already have encountered it as a build tool.

What I have

Here I have a first working version. For this I've already:

• Tested the compilation for all the targets with Intel oneAPI + MKL + STRUMPACK + HDF5 on Pitagora, TOK, and Viper. The resulting binary ran model600 for both fluid-only and fluid+kinetic.
• Instructions on the new workflow can be found here.
• I dind't check MUMPS and PASTiX or other compilers.

It would be great if people can take a look at it and try it out so we can find out what's missing.

For now the idea is to keep the two build systems in parallel for a transition period and gradually move to CMake.

What people think about it?

[N-Schwarz]

Hi Edoardo,

This will be very useful. I quickly tried it, the compilation is quite fast and the output is a lot cleaner.
I just have some questions

• Does it automatically detect when it has to rebuild? E.g. After changing the hardcoded parameters?
• Can we still change the parameters with the same script?

This already looks very good, we have to test it on different machines and different configurations to make sure it works for everyone.
I tested on pitagora:

• Changing hardcoded parameters wokred
• It didn't detect the change in the model when I changed from 600 to 303. Only after deleting the build folder, it compiled the correct one.

[edo01]

Hi @N-Schwarz,
Thank you for taking a look and trying it out!

In order:

1. If you modify a file, it should in principle just recompile that file and all its dependencies (exactly as the Makefile does, hopefully more efficiently). I wouldn’t trust the hardcoded parameters, though. It might work, but to be safe, I would do a cleanup first.
2. Yes, I already adapted ./util/config.sh to use CMake.
3. Great!
4. Yes, you are right. I don’t think there is a workaround for that: if you switch the model, you have to clean up and rebuild everything from scratch.

[edo01]

@patrikrac suggested that centralizing all the machine configurations in a single file is not optimal. His proposed solution would be to provide a template that users can fill in themselves, or alternatively copy a pre-filled version from somewhere else (maybe a shared dir on the cluster).