Build systems

[milancurcic]

Use this issue to discuss and propose build systems and/or methods.

Some candidates so far:

• autotools (configure && make && make install);
• CMake
• Hand-written Makefiles

[scivision]

Meson generally has better Fortran support than CMake.

[zbeekman]

Can you elaborate on particulars, @scivision?

I don't have much Meson experience, but CMake has a whole host of useful infrastructure for reproducible builds, finding MPI, introspection, following standard installation conventions, writing package config modules, testing... And I've found recent versions to have excellent Fortran support.

[certik]

I would recommend CMake as it is known to work on all platforms with excellent support and usage in lots of projects. So we know it will deliver, even though I don't like how easy it is to write ugly CMake files.

In addition, I think we should maintain simple manual Makefiles (and test them on CI), to show how to compile it by hand. So that people can easily integrate things into their projects.

In particular, I would like the stdlib to be preferably written in a way so that big projects can simply copy the files into their repository and things will just work.

I have done exactly that in https://github.com/certik/dftatom and I have seen people do both: some people use the provided cmake build system, and some other people literally copy the .f90 files into their project. And so I recommend for both to be easy. In addition to CMake, it has manual Makefiles:

https://github.com/certik/dftatom/blob/fe479fd27a7e0f77c6a88a1949996406ec935ac2/Makefile.manual
https://github.com/certik/dftatom/blob/fe479fd27a7e0f77c6a88a1949996406ec935ac2/src/Makefile.manual

As you can see they are super simple, and so there is value in having those in addition to CMake.

[zbeekman]

My only complaint about standard Makefiles is that dependency resolution can get pretty hairy. Also, a potential issue with standard makefiles is you may want to alter the build based on system introspection. For example, if you need to work around a compiler bug. But as long as I don't have to write maintain vanilla Makefiles, (or auto-hell) I'm happy to defer to others' preferences for including vanilla makefiles.

[scivision]

I think CMake is a good common ground. Meson supports more submodule syntax than CMake, but it's not a big deal here. Maybe if we try to keep the common build system choice (perhaps CMake) as the one that's known to work for everything, it wouldn't hurt to have other build systems also available e.g. Meson. This is what I do for most projects, although for me Meson is the primary choice.

A prime example: https://github.com/scivision/fortran2018-examples/
CMake and Meson are generally equally supported, except for a few things needlessly tricky in CMake, I did only in Meson. Each directory has CMakeLists.txt and meson.build that are independent, to allow users of either build system to enjoy.

[zbeekman]

@scivision I'm curious which submodule features are missing from CMake? Their Ninja patch was upstreamed and should be included in the next release of Ninja, and I've been using submodules extensively without issue since 13.4.3 with MSVS and Makefile generators.

[scivision]

for CMake, consider requiring at least 3.14 so that check_fortran_source_runs is available, or at least if() else() it. That's necessary to check if Coarrays are fully working to avoid confusing runtime errors. A compile/link check is not adequate.

[scivision]

This doesn't work with CMake, last I tried https://github.com/scivision/fortran-submodule/blob/master/src/parent1.f90

MODULE PURE SUBROUTINE or module pure function

[certik]

I would suggest we do not use any features that CMake can't support. See #15.

[zbeekman]

FWIW, the issues reported have an easy work around that gets CMake to work:

Switch MODULE PURE SUBROUTINE to PURE MODULE SUBROUTINE. Additionally, within an interface block this is a non-issue, as far as I can tell.

This is an issue only when you have a separate module procedure and the first prefix-spec is MODULE followed by additional prefix-specs then SUBROUTINE, FUNCTION or PROCEDURE outside of an INTERFACE block. See https://gitlab.kitware.com/cmake/cmake/issues/18427 for a discussion.

[milancurcic]

We're currently using both Make and CMake (user's choice).

We will transition to fpm soon. @LKedward has an stdlib mirror as an fpm package here.

I will go ahead and close this in favor of #279.