Mod file completeness

[aradi]

I would find it useful, if the standard required mod-files to be complete / self-contained. Given a library consisting of several modules and a wrapper module exposing the public API

module library_api
  use library_module1
  use library_module2
  implicit none
  private

   public :: public_entry1, public_entry2

end module library_api

the standard should enforce, that the mod-file generated for the module library_api should contain all information necessary to import the module (via use library_api) in any application.

Currently, there is at least one compiler I know (NAG), where use library_api requires not just the presence of library_api.mod, but also all the modfiles for the modules imported by library_api directly or indirectly. This is annoying, if you want to distribute the library in binary form, and it also unnecessarily exposes the internal structure of the library (and enables the consumer to basically import any module of the library directly and call routines from it).

[klausler]

The standard has nothing to say about module files, not even their existence.

Is it possible to always "flatten" modules in Fortran into single modules, even in the presence of renaming?

[sblionel]

The problem here is that when you have large, nested modules the module files become enormous and slow down compilation. DEC Fortran started with making each .mod file self-contained, but the impact on build times was intolerable, so it shifted to opening each .mod as needed.

For library developers what you usually need to do is separate public and private interfaces and definitions. Submodules can help. As for distributing in binary form, this simply does not work as each compiler has its own binary format and its own API into the support library.

[klausler]

Why is one combined module file bigger/slower than the combined size of the transitive closure of the module files that it uses?

[FortranFan]

I would find it useful, if the standard required mod-files to be complete / self-contained. ..

This is outside the purview of the current standard. Before something like this can even be considered, a clear vision and scope would need to be developed toward which all aspects of implementation details should be covered by the standard. That is a monumentally difficult thing to pursue.

[aradi]

For library developers what you usually need to do is separate public and private interfaces and definitions. Submodules can help. As for distributing in binary form, this simply does not work as each compiler has its own binary format and its own API into the support library.

@sblionel Thanks a lot. Yes, exactly, I would wish for a good support for exposing only interfaces which are meant to be public. If I think about submodules, then the entire library would have to be a single module (containing the public API of the library) with several sub- and sub-sub-modules containing the actual implementation details. Is this the way you suggest?

[certik]

with several sub- and sub-sub-modules containing the actual implementation details. Is this the way you suggest?

Submodules do not scale in my opinion to large libraries, as explained in #86. The issue #86 was one of the first issues that I had when I joined the committee, but I only created an actual GitHub issue for it now. I got reminded of it, since this issue #84 is very similar to #86.

[aradi]

Yes, nested modules are a nice idea, I fully support it (see my comment there). But, it still does not solve the problem, that you may need to expose the internal structure of your library (in form of having to provide the mod-files for all modules in it), when it should be imported by a program. In C / C++, you would only install the include file for the public API, which I find much cleaner. But in terms of costs, maybe this proposal would not be worth the effort, indeed. So let's concentrate on nested modules (#86) instead.

[zerothi]

I would support this effort for fortran.

A big problem with fortran libraries is the requirement of shipping together the compiled *.mod files. And so having a uniform way in the standard to define module/include files for external use is paramount to not complicate matters for end-users!

Using compiler A with dependency on library X compiled with compiler B is currently a nightmare!
Currently one is just told: don't do this but this is limiting the use of fortran I think!

[aradi]

@zerothi Unfortunately, this proposal would not solve the issue you raised. Since the Fortran libraries compiled with various compilers are not ABI compatible, it still remains, that all modern Fortran libraries your project depends on must be compiled with the same compiler.

[zerothi]

Exactly. :)

In addition to what you have here it would be ideal if the module files are not binary files, or at least ensures that different compilers can inspect the interfaces/derived types in a non-compiler specific format.

[klausler]

The format of module files is not within the purview of the standard. (f18 uses a module file format that any other Fortran compiler could inspect, though; maybe that will help you someday.)

[zerothi]

The format of module files is not within the purview of the standard. (f18 uses a module file format that any other Fortran compiler could inspect, though; maybe that will help you someday.)

But why could it not be part of the standard? ;)
This problem is recurring and prohibits system admins from choosing fortran coding for sys-tools (granted it isn't made for this but...).