Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26745 Discussions

How to avoid distributing .MOD files with Fortran libraries

joseph-krahn
New Contributor I
325 Views
A .MOD file is essentially the same as a precompiled header in C, except that precompiled headers are just temporary files whereas .MOD files generally must be part of a library distribution.

It is not essential to be so depenent on .MOD files to define the interface. Instead, a library could distribute the equivalent of a header file, which would be the module source files stripped of procedure bodies. You then just do a "dummy" compile to produce a .MOD file, and delete the resulting object file. The usefulness of this approach depends on several things:

1. Does the MOD file format ever change without changing the binary interface? If so, this would avoid the need for multiple .mod files where they are not really needed.

2. Are .MOD files built in a way that missing procedure bodies would affect the resulting interface definitions? (Maybe compiler dependent.)

3. Are stripped sources generally smaller than .MOD files?

With F2003 support, a Fortran library could be designed using all BIND(C) interfaces. The binary interface would not be compiler dependent, and the stripped source interface spec would be applicable to all Fortran compilers and versions.

Of course, a BIND(C) library can simply have interface specifications, and a user can simply INCLUDE it in a wrapper module body to get the benefits of module use and rename features.
0 Kudos
3 Replies
Steven_L_Intel1
Employee
325 Views
I don't quite understand your questions or statements. A .mod file is one of the results of compiling a module - the .o file is the other. The .o file may not be needed if the module has only type and PARAMETER declarations, but if there are default initializations the .o file may be needed. If all you have are interfaces, the .o is not needed.

The .mod is input to another Fortran compile which makes the module available to a USE. You can certainly choose to provide the source of the module instead and ask the user to compile it, but that will be larger and will expose more code.

The .mod file format has changed over the years, but we try to make it upwards compatible so that you can use a newer compiler. There have been some exceptions to this due to compiler bugs.

I don't understand your question 2. .mod files don't contain procedure bodies - those are in the .o file. They will contain information about module procedures (the interface).
joseph-krahn
New Contributor I
325 Views
Actually, what I really want is to use submodules (I just read the specs). My idea was to make an interface-only module source file, similar to Intel's 'ifcore.f90', but also include interfaces for module procedures. My idea was to emulate the submodule's module procedure interface, using a version of the source file with missing procedure bodies, which could be used to generate a valid .MOD file, but with an invalid object file.

With submodules, it will be easy to distribute an interface-only parent module that defines an API, and is essentially the source equivalent of a MOD file. Hopefully, that will become the standard way to define a Fortran library API.
Steven_L_Intel1
Employee
325 Views
I suppose you could do that, but it hardly seems worth the effort to me. I agree that submodules will be very nice.
Reply