Multiple Fortran source file extensions

[Yann Pouillon]

The use of file extensions in LibGridXC is quite heterogeneous. All main Fortran file extensions are found in the library, e.g. bessph.f, ggaxc.F, mesh1d.f90, xcmod.F90. This situation has 3 main drawbacks:

  - preprocessing options can only be transmitted to some of the source files, thus precluding systematic testing and debugging of the code;
  - different coding styles (free-form and fixed-form) coexist within the same library and will not be treated with the same rigour by most compilers, which will cause portability issues and let some bugs escape early detection;
  - if a file is currently not preprocessed and becomes so in the future, some keywords might accidentally be substituted if preprocessing macros are not designed with sufficient care and the file has no corresponding unit test.

The most widely used file extension is currently .F90. We recommend its use for all Fortran source files of LibGridXC, which will likely allow the detection and/or triggering of dormant bugs and design flaws.

[Alberto Garcia (albertog)]

OK.
Do you have a favorite way to invoke the pre-processor? There seems to be quite a lot
of variability in their behavior (cpp (several variants) vs. built-in preprocessor in gfortran, for example). Nick has had a hell of a time with this.

[Nick Papior (nickpapior)]

Yes, the preprocessing variants may be very different from different compiler suites and/or distributions. Generic cpp behaves very different from gcc-cpp, let alone ifort pre-processor.

I am very positive about the upgrade of the codes to a common standard. However, the capitalisation I have found very useful from time to time. I.e. a non-capitalised source does not get preprocessed (as is commonly used in compilers).

If one retains the capitalisation one can immediately see from the file name whether it gets preprocessed, or not. So I would probably like to retain this form. If a file should be pre-processed then it has to change name.

Again, I think you should decide. :)

[Yann Pouillon (pouillon)]

My philosophy is to use the ".F90" extension only and add the following at the beginning of every single Fortran file:

#if defined HAVE_CONFIG_H
#include "config.h"
#endif

This makes it much easier then to write makefiles (only one extension for all source files) and track dependencies automatically (scripts are easier to write and understand, with less if's). When a previously non-preprocessed Fortran file starts to include preprocessing options, there is no need to change anything in the build system. All this has a positive impact on developers, in particular on newcomers, who need as much clarity and straightforwardness as possible.

However I don't want to enforce any practice. If you prefer to selectively preprocess Fortran files, I'll follow your specifications.

[Nick Papior (nickpapior)]

I generally have no decide to force something, I am just happy for the current capitalization currently, because it is easy to see whether it makes use of pre-processor statements.

You are the expert in autotools, so if you think this is for the better, then fine by me :)

Up till now the philosophy in the build-system was implicit rules which never required a change in the build-system when changing the extension. But if your build-system will use explicit rules, then yes we should convert to a common filename (.F90).

I just felt like commenting ;)

[Yann Pouillon (pouillon)]

Your comments are actually of great importance. My priority is that you developers feel at ease with the proposed changes and that they fit as well as possible with the way you like to work. Technology is (or should be) there to help us do our work, not to tell us how to do it.

If you tell me that keeping different file extensions matters to you, I'll keep them there. If not, having just one extension will make your life easier. At the end, what truly matters is what helps you happily contribute to the project.

Shall we go for "everything .F90", then?

[Nick Papior (nickpapior)]

Ok. Thanks.

I have no preference, I will adapt if it allows easier maintenance of the autotools stuff. So from my part you have a go :)