Module expert needed

[Damian Rouson]

> On Aug 6, 2015, at 2:53 PM, FX <fxcoudert@gmail.com> wrote:
> 
>> I would rather not bother with either.
>> The .mod is the external (public) interface, and the .smod the internal (full) interface needed by submodules.  It's simple, albeit somewhat redundant.
>> 
>> Symbols may reference each other, through initialization, array specs etc.  I don't think it would be a good to pick them from two different places.
> 
> What bothers me is that, if it is by design, all existing build architectures (makefiles, build scripts) will now need to be adjusted.

Most people who use the newest language features are early adopters who are also be willing to use the newest build systems.  Considering CMake, for example, it is is very likely that either no adjustment will be needed or Kitware will make the necessary adjustments.  I discussed submodules with the lead CMake developer in May and came away with the sense that the required adjustments, if any, will not be problematic.   Kitware has been very responsive to the needs of modern Fortran so the worst-case scenario is that CMake users would have to set a recent CMake version as a requirement for building Fortran programs that have submodules, but that is already the case.  For example, the cleanest approach for building coarray programs necessitates using a recent release (CMake 3.0 or higher).  As another example, detecting the version number of the Fortran compiler at build-time requires the latest release (CMake 3.3.0). 

Unlike Make, CMake does some limited parsing of Fortran and figures out dependancies for itself so that it can generate Makefiles automatically.  CMake also attempts to avoid unnecessary compilation cascades by factoring the .mod files into the dependency graph.  I imagine they’re just using the time stamp on the .mod file, but if no public information changes when the source file is rewritten, that would be sufficient with the approach that Paul has implemented.  

> 
> How do other compilers deal with that?

When Paul first started, I sent him the following based on my testing with two compilers:

Cray: submodule_name.mod
Intel:  module_name@submodule_name.smod

Unfortunately, I’ve in the middle of a lengthy international trip and haven’t had time to double-check these.   In particular, I’m not sure whether either vendor writes two files for modules that have private entities.  I hope to have time to check soon.  

IBM also supports submodules.   I don’t have easy access to an IBM system, but I’ll check with a member of their compiler team on their convention.

Damian