Having experience with managing such software on HPC systems, I’ve regularly come upon projects that offer Makefiles for the configuration and compilation steps.
In most cases, it’s a nightmare to follow the documentation, edit the correct flags at the correct places with the appropriate paths, then pray that other external dependencies don’t need their own makefile edits.
Build systems should replace the need for makefiles completely. Case in point, autotools generates a non-human-readable makefile automatically, occasionally ~16k lines long.
My favourite process for Fortran codebases that need to be developed and run both locally and in HPC systems (and don’t implement a build system like cmake or meson already) is to:
- migrate to
fpm: As you point out, it’s very straightforward in many cases - manage a Python virtual environment: In it’s simple form it only requires Python, and is just
python -m venv .venv; source .venv/bin/activate - install
fpm(and other tools) on the project’s virtual environment:(.venv)$ pip install fpm - No other changes required:
(.venv)$ fpm build
I feel that this is easier to manage than any makefile. It follows modern standards and (until now) it’s completely portable within Unix. I believe only slight changes are needed for Windows.
Also, fpm.rsp is not be underestimated. Trying to get a makefile to support a) multiple compilers, b) multiple OS systems, c) multiple modes of compilation (release, debug), d) differing compilation flags is downright silly.
I’ve also created a project template for such projects to make migration even easier.
I hear you about potentially finding out features that fpm cannot support. It’s always a risk.