fortran .mod files

[Tobias Burnus]

Billinghurst, David (RTATECH) wrote:
>> On Tue, 23 Oct 2007 21:24:10 +0100 FX Coudert wrote:
>>     
>>>  From what I remember, we have never formalized this. The current
>>> consensus, as I understand it, is that while there is no guarantee
>>> on compatibility, modules files are actually compatible within
>>> releases of the same branch (4.2 is a branch, 4.3 will be another
>>> one), unless of course there is a bug nasty enough to mandate fixing
>>> (a regression wrt to a previous release) that crept into module
>>> format. I don't think such a thing has occured for 4.2, but others
>>> may be more affirmative than me on this point (Paul or Tobias ?).
>>>       
>
> Can the testsuite check this?  Should it?
>   
Well, the MOD files are kind of memory dumps of the interfaces of a
module; many compilers use even binary files. Mod files are seen as
temporary files, generated when the same compiler compiles different
part of a project; they are not supposed to be interface files.

I think in terms of the how the Fortran standardization people see it,
any project should re-compile the Fortran source file, which contains
the interface to the contained procedures and the module variables. In
this sense, one would have "/usr/include/netcdf.f90" rather than
"/usr/include/netcdf.f90". This is not how it is done in practice and
"/usr/include" is also not searched for "modulename.f90" when using "USE
modulename", but this approach would be 100% compatible with all Fortran
compilers.

In order separate the interface part of a module (which should be a
Fortran source file) from the actual implementation (which might be a
binary file or library), sub modules were introduced as Technical Report
which allow this ("Enhanced Modules", ISO/IEC TR 19767:2005(E)).
However, to my knowledge there is not a single compiler implementing
this TR.

For .mod files for libraries written in C the TR is not needed as the
module source files only contain the interface of the program and not
the program itself. This is also possible for Fortran programs, but
clumsy without the TR. One can also use the normal Fortran modules,
which has two disadvantages: (a) The source code of the routines is
available and (b) one the compile time might be rather long not only the
interface information has to be read but als the program itself is
compiled [which is especially not needed when linking libraries].

Regarding gfortran: The .mod format is rather stable and as no major
features get introduced in branches, the .mod files should be compatible
all minor releases. However, 4.1.x, 4.2.x and 4.3.x are incompatible,
though depending on the module a given .mod file might be compatible.
(The file format allows that minor differences don't make the file
unreadable.)

We don't have formal tests for the .mod compatibility, but since 4.3.0 a
MD5 number is saved in the .mod file and thus one needs to actively
change the MD5 number if an incompatible change occurred. (Though some
changes might get undetected as the module-test module file in the
testsuite does not use all features.)

Even during the trunk development, the .mod files change only rarely. I
think we can declare that we do try hard not to change the .mod file
format for branch releases and at least consider whether .mod format
changes can be prevented between major releases to make 4.3-compiled
libraries' .mod files compatible with 4.4-compiled programs. (Still, it
is very likely that 4.4 will have a incompatible .mods due to the
implementation some Fortran 2003 features. And, having a clean code will
be more important than having a stable .mod file between major releases.)

Tobias