Debug/release versions of .mod files

[Simon_B_2]

If I have separate debug and release versions of a Fortran module, the difference being solely one of compiler flags, will the .mod file differ between them? In other words, is it necessary/advisable to change my include path depending on which version of the module I link to? I know the .mod file is a compiler-generated binary, but as a Fortran newbie coming from a C background I'm not sure whether I should be thinking of it as akin to a precompiled header or more like an object file in its own right.

Thanks,
Simon

[pbkenned1]

Hello Simon,

I don't think there is any material difference between debug and release .mod files.  An -O2 (release) build should be able to use -O0 (debug) .mod files, and vice versa. 

.mod files are binary files, and the format may change between major compiler releases, but we try to maintain compatibility across major releases (breaking changes that require recompilation should be documented in the Release Notes). 

Patrick

[Izaak_Beekman]

mod files are even generated when you don't compile object files (by adding the -syntax-only flag) so there shouldn't be any differences between mod files created with different optimization flags. N.B. However, AFAICT the standard is silent on this matter. Therefore, theoretically, this behavior is not guaranteed for all compilers, although I would be very surprised to find one that didn't act in this way.

In practice, with most compilers, the mod files contain interface information about any module procedures, module variables, derived type declarations, named constants. This means that they shouldn't change if you change algorithm implementation details in module procedures without changing their interfaces. One can use this information advantageously in one's makefile/build system to prevent compilation cascades. The trick I use is to locate all mod files in a build subdirectory using the -I flag. Then each time a mod file is created it gets placed in the local directory by default. I then run a cpm between the newly created mod file and the any preexisting copies in the build subdirectory. If they are the same, I just delete the new, local mod file. If they differ, move the new mod file into the build subdirectory to clobber the old one, and let make know that any object files that use this module need to be recompiled.

I actually have a project which I claimed I would post some weeks ago which does auto-dependency resolution, compilation cascade prevention and Emacs flymake implementation using the Intel Fortran compiler and gfortran, but I'm still polishing it up a bit. I should have it up on github soon, and will post to this forum in the event that others might find it a useful tool.

[Simon_B_2]

Thanks folks, this simplifies my makefiles nicely! My immediate concern was packaging common code into clean reusable libraries, but this thread has given me a much better idea of how to manage internal dependencies as my projects grow in size.

Thanks again,

Simon

[Izaak_Beekman]

The one caveat about libraries is that the .mod files are in a format unique to each compiler vendor, and can change between compiler version from the same vendor. So, unless you have a guarantee that the library users are using the same compiler, in general you can't just ship off lib____.a files along with ____.mod files and expect them to work, unless the consumer uses the same compiler and version.

[Steven_L_Intel1]

I'll also comment that Intel Fortran .mod files are specific to the platform (OS and 32 vs. 64 bit). We DO try to keep .mod files upward compatible, so you can use them with a newer compiler version (but often not an older one, depending on how old....)