scons: Fortran 2008: SCons don't recognize .smod files

After I performed the investigation of how different compilers handled smod files, I unfortunately didn’t have time to follow up and after a while didn’t think about it anymore. Mainly because I don’t see too many problems with this in my daily work. Thanks for pinging the issue. Maybe it’s time for me to get on the the discord server and try to get things moving again.

Please try latest SCons and verify this is still an issue? (most likely it is, but there were lots of changes in 4.0.0)

If not, PR’s welcome. Please come to our discord server #devel if you want help on how to get started with such. Also see: https://github.com/SCons/scons/wiki/DeveloperGuide

As I have recently seen some issues with building in parallel that I expect to be related to this issue, I decided to look into how different compilers handles submodules and I will try to summarize my understanding of this here. I looked at gnu’s gfortran, intel’s ifort and pgi’s pgfortran.

Submodules are intended to be used to separate the interface of a module with the implementation, in order to, among other things, avoid recompile cascades if the implementation of a module changes but the interface does not. Any fortran routine that USE a module does not need to be recompiled if the interface does not change.

Submodules are fairly different from modules. The main difference is that other fortran code will never USE a submodule. In the case of just 1 levels of submodules, any submodule will have one (and only one) parent module. If there are multiple levels of submodules, the submodules parent will be another submodule, but then it will still have an ancestor module. Submodules may USE other modules and have INCLUDE statements. There may be multiple modules and submodules defined in the same fortran file.

A first level submodule is defined by:

SUBMODULE(module_name) submodule_name

In this case the module module_name is the parent of the submodule submodule_name.

Submodules can also have submodules, in which case the definition is:

SUBMODULE(module_name:submodule_name) submodule_name2.

Here the submodule submodule_name2 is defined with the submodule submodule_name as it’s parent and the module module_name as it’s ultimate ancestor.

The definition of a third level submodule can then be done with:

SUBMODULE(module_name:submodule_name2) submodule_name3,

which defines submodule submodule_name3 to have the submodule submodule_name2 as it’s parent and again module module_name as it’s ultimate ancestor.

Unfortunately I found that the three compilers I looked at (gnu, intel and pgi) all handles submodules slightly differently. Whenever a fortran file with a module is compiled, all three compilers generate a .mod file named after the module name, i.e. module_name.mod. The gnu compiler will, in addition, generate a ‘.smod’ file named after the module, i.e. module_name.smod. This happens even if the file only contains the module definition. I’m not sure what criteria needs to be satisified for the compiler to do this. In all the cases I have checked, the .mod and .smod files are identical.

When a file containing one or more first level submodules is compiled both gnu and intel compilers will generate a .smod file for each submodule. The name of that file is module_name@submodule_name.smod. The pgi compiler on the other hand never produces .smod files, instead it will produce an additional .mod files for each submodule. The name of that file is module_name-submodule_name.mod. For the intel and pgi compilers compilation of the file with the submodule requires the presence of the .mod file of the parent module, whereas the gnu compiler requires the presence of the ‘.smod’ file of the parent.

For deeper levels of submodules the behavior is similar. The gnu and intel compilers produces .smod files for each submodule with the same naming scheme as above, i.e. for the case of a submodule of a submodule (as above) the name will be module_name@submodule_name2.smod. Similarly the pgi compiler produces .mod files with the name module_name-submodule_name2.mod. Here there is an additional slight difference. When using the gnu compuler only the .smod file if the immediate parent is required. However, when using the intel or pgi compilers all the .smod (for intel) and .mod (for pgi) files for all parent and ancestor submodules as well as the .mod file for the ancestor module are required.

As mentioned above submodules can USE other modules and also INCLUDE, so this of course adds additional dependencies.

The final link stage does not require any of the .mod or .smod files. Only the .o files produced from the files that contains submodules are needed at that point.

It is of course unfortunate that different compilers behave so differently, but as far as I know the Fortran standard only defines how modules should behave from a programmers standpoint and not how compilers work with them internally. I currently do now have access to any other Fortran compilers, so there could be some other possible behavior out there.

I hope this information is enough for somebody, more familiar with the SCons build system than I, to find a way to add proper submodule support to SCons. If something is still unclear, please ask and I’ll be happy to investigate and try to clarify.