François-Xavier Coudert wrote:
Well, I think the constraints detailed in that thread are correct,
including the fact that they are architecture-dependent. Moreover,
something that might not have been considered by you until now is that
they also are compiler-dependent: different compilers will generate
different .mod files for the same source, and different versions of
the same compiler might generate different .mod files.
For Linux distributions the
latter part should be no problem as there is
usually only one true system compiler. (Even if the distributions ships
several compiler such as gcc 4.1, 4.2 and 4.3, usually the libraries are
only compiled by one of them, e.g. 4.2.)
For this reason, I think it's considered bad programming style
for a project to
require mod files from another project in order to compile.
I'm quite happy
that I can use the libraries which come with my linux
distribution without needing to compile blas, lapack, netcdf, openmpi,
fft etc. myself.
We had some discussion a while back about where to put module files,
but a conclusion was easier to reach because we were only dealing with
gfortran intrinsic (or "internal") module files, so we ended up hidding
them inside the gcc directories
At least on my system this gives the
*same* directory for -m32 and -m64
(see output by "gfortran -v -c -m32 file.f90"). Actually, only the 64bit
version is installed on my x86_64-unknown-linux-gnu system.
Now, my personnal opinion is that since these files are
compiler-generated and target-dependent, they are very similar to
libraries. For that reason, I think they probably should be placed in
/usr/lib*/finclude, or in /usr/finclude*, where * can be 32, 64 or
I see two proper places:
a) A library/compiler specific place; this would be the natural choice
for a non-default/system compiler, e.g.
This always works, but one needs either a wrapper ("mpif90") or to
specify the -Ipath.
b) A generic place for the system compiler, here, I like the location
or, why not, /usr/lib*/<compiler,version,target,-m* options>/finclude
For (b) one still needs to make it generally work that -m32 and -m64
have different search paths; this is (see above) currently not the case.
I don't know whether one needs to distinguish other -m* options as well
-- such as e.g. IA64's -mbig-endian/-mlittle-endian etc.