This is the mail archive of the
mailing list for the GNU Fortran project.
Re: [Fedora-packaging] fortran .mod files
- From: Ralf Corsepius <rc040203 at freenet dot de>
- To: Discussion of RPM packaging standards and practices for Fedora <fedora-packaging at redhat dot com>
- Cc: Ed Hill <ed at eh3 dot com>, fortran at gcc dot gnu dot org
- Date: Mon, 22 Oct 2007 17:44:35 +0200
- Subject: Re: [Fedora-packaging] fortran .mod files
- References: <20071020222443.GA23353@free.fr> <firstname.lastname@example.org> <email@example.com> <471CBD5C.firstname.lastname@example.org>
On Mon, 2007-10-22 at 17:10 +0200, Tobias Burnus wrote:
> Ed Hill wrote:
> > https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html
> > And, here is a concrete example:
> > 0) netcdf provides a netcdf.mod file
> > 1) the mod file provided for i386 is (aha!) not identical to
> > the one provided for x86_64 (and for ppc/ppc64)
> > 2) we'd like to be able to simultaneously install both
> > the i386 and x86_64 versions (and ditto for ppc/ppc64)
> > 3) where, in your opinion, is the "best" or "standard" place to
> > put the netcdf.mod files?
> .mod files are in a way like C's .h file:
Are they processed by cpp?
IMO, there should not be anything under /usr/include which can't be
processed by cpp.
> They store the interface of
> procedures (functions). However, they are generated from a source code
> file which contains a module (= collection of procedures, type
> ("struct") declarations and module variables).
> As they are generated from a source file, their content may differ
> depending on the preprocessor flags and processor-defined variable (e.g.
> size of a pointer on 32 bit or 64 bit systems).
> As C's include files, -Idir can be used to add more directories to the
> .mod (and "include" and the preprocessor's "#include") path.
Well, I am not sure GCC using -I<> has been a clever decision, but
that's beyond the scope of this thread.
> Thus the natural place would be, e.g., /usr/include/netcdf.mod (where it
> is on my openSUSE system).
> However, as noted, this makes problems on systems where both a 32bit and
> 64bit version has to be provided.
Exactly. Therefore it would be natural to put them somewhere inside of a
multilib'ed subdir ($libdir/<multisubdir> in GCC terms, %_libdir in rpm
> I have frankly no idea how to solve this. You could put the files into
> different directories, but then the user has to specify the path which
> is rather inconvenient. One could also put the default file (the one
> generated without specifiying e.g. -m32 or -m64) into /usr/include and
> put the other version somewhere else. Or ...
How do other languages which have similar files, such as Ada, Modula 2
and some variants of PASCAL handle this issue?
IIRC, ancient VAX/VMS Pascal/Modula installed their *mod equivalents
(Sorry, this his was > 15 years ago) next to their libraries.