File name and locations conventions

[joseph-krahn]

Here are some ideas on standardizing Fortran binary module and library files. I would like to get some good conventions defined to allow for better packaged Fortran development libraries. There seems to be no good convention for where to put module data files for Fortran development packages. Compilers generally check both include and library search paths for the .mod files. When it comes to installed packages, /usr/lib and /usr/include are both incorrect.

According to FHS, /usr/include/ is specific to the C programming language. Therefore, even Fortran include files should not be installed in /usr/include.

The /usr/lib directory is defined by FHS as "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts." This is a bit vague, so one could argue that .mod files could be installed there, although only for one system-dependent compiler.

A better solution is to use a subdirectory in /usr/lib, which is the correct place (by FHS) for application-specific files. This also follows the general scheme for other non-C languages. For example, /usr/lib/perl contains subdirectories that allow for binary files that are part of both a specific compiler version and a specific Perl package. Given that Fortran module interfaces are not part of the system ABI, I propose that even the library files for the platform-supplied Fortran compiler should reside in a version-specific subdirectory of /usr/lib.

My idea os to do something like this, assuming Intel Fortran 10.0 for this example:

/usr/lib/ifort/10.0/lib -- library files
/usr/lib/ifort/10.0/include -- INCLUDE files (i.e. non-module based)
/usr/lib/ifort/10.0/modules -- binary .mod files
/usr/lib/ifort/include -- INCLUDE files (if not version-specific)
/usr/lib/ifort/src -- source files to generate the .mod files (if possible)

In the case of generic INCLUDE files that have no compiler-secific contents, the correct place is probably in /usr/share/fortran. Also, module source files should be included when possible. Currently, this is only practical for interface modules (i.e. sources in ifort's library dir). Eventually, I think the SubModule TR spec makes it possible to provide a sort of "header only" module source.

Joe Krahn

[Steven_L_Intel1]

In Intel Fortran, the compiler does not look at all in library paths for module files. It leaves library paths to the linker.

Unfortunately, Linux is "A twizy maze of little distros, all different". You can't even get consistency from one release of the same distro to another, much less across all of Linux.

[joseph-krahn]

It is true that Linux distributions vary a lot, due to random mixes of design ideas, without enough concern for backwards compatibility. It's like traditional Fortran code: "Change GLIBC parameter XYZ and recompile the OS and all applications".

However, filesystem standards defined in FHS are one place where consistency is improving, and it would be nice to make Fortran binary distributions more consistent as well. Fortran binaries are more complicated than a C binary, due to modules and the lack of a common ABI, yet people try to work it into the usual C organization. I'm suggesting that a more detailed scheme is needed, especially if more than one Fortran compiler is installed. Consider it a bit like having multiple Perl packages installed.