Location of .mod files?
Wolfgang Kilian
installed. For instance, executables go into some 'bin' directory,
libraries into 'lib', etc.
Is there any recommended location for Fortran '.mod' files, when
installing a Fortran library? The library itself should go into 'lib'
(the .a or .so files).
In analogy to C/C++, one might choose 'include' (since the .mod files
are accessed in a similar way to header files), but there is an
important difference: the C header files are compiler- and
machine-independent, while Fortran's .mod files are compiler- (and
possibly machine-)dependent. This would suggest to choose a
subdirectory of 'lib'.
Any recommendations? Common practice?
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
Arjen Markus
> Domain: yahoo
I would say that the lib directory is a good choice, since, as you
point out, these files are specific to the platform.
Regards,
Arjen
Tobias Burnus
> > Is there any recommended location for Fortran '.mod' files, when
> > installing a Fortran library? The library itself should go into 'lib'
> > (the .a or .so files).
Not really.
> > Any recommendations? Common practice?
I think a common practice for Linux distributions is to place them in /
usr/include, which is admittedly not the best place. For "mpif90" one
has the advantage that there is a wrapper - thus they can be placed in
specific directories.
If one has one own's library, one simply uses the /usr/local/mylib/
$version/$compiler/{include,module,whatever} directory for the module
file - by specifying the directory as search path.
> I would say that the lib directory is a good choice, since, as you
> point out, these files are specific to the platform.
I think that position is worse than /usr/include; while the latter is
in the search path, /usr/lib{32,64} etc. is not. Additionally, it does
not solve the problem of the compiler (version) dependence.
(Side note: I think the Cray ftn compiler by default embeds the module
information in the .o and thus in the .a files, avoiding the need
for .mod files.)
Jakub Jelinek (of Red Hat) suggested once that one should use
something like /usr/{local,}/include/finclude/
<compiler,target,version> such as /usr/{,local/}include/x86_64-unknown-
linux-gnu/4.7.0/ -- and make the compiler automatically search in
those directories. One could also argue that the name should be /usr/
{local/,}/lib/finclude instead.
However, such a patch has not been written for gfortran - and I think
other vendors have also not done steps into that direction. But I
agree that it makes sense to think about that.
(Another thing I was thinking about was on-the-fly generation of .mod
files: If the .mod file couldn't be found for "USE module", the
compiler searches for the "module.f90" files (e.g. in only some
directories like /usr/{local/,}include/finclude/) and automatically
compiles it to generate a .mod file (and no assembler/object file). I
think that would be in the spirit of the standard where the Fortran
module (source file) is the authoritative source, which is compiler
independent. For that, submodules would be also handy. I do not see
that happening soon, however.)
Tobias
Carlie Coats
>[snip...]
> (Another thing I was thinking about was on-the-fly generation of .mod
> files: If the .mod file couldn't be found for "USE module", the
> compiler searches for the "module.f90" files (e.g. in only some
> directories like /usr/{local/,}include/finclude/) and automatically
> compiles it to generate a .mod file (and no assembler/object file).
What about putting the following into your "makefile" (it doesn't
work for "system" sourcefiles, but does work for your own)
.SUFFIXES: .m4 .c .F .f
...
SRCDIR = <your source directory>
OBJDIR = <HW/OS/compiler/flag-dependent "build" directory>
...
%.o : %.mod # Disable "gmake"s obnoxious implicit Modula-2 rule
.f90.mod:
cd ${OBJDIR}; ${FC} ${FFLAGS} -c ${SRCDIR}/$<
Wolfgang Kilian
Well, our Makefiles are way more complicated than that ...
(using Automake and a hierarchy tree of packages). It compiles into a
set of installed libraries, and the question about .mod files arises
when I want to build additional Fortran software that uses the
functionality (derived types, methods etc.) encoded in those libraries.
Wolfgang Kilian
> On May 3, 9:44 am, Arjen Markus<arjen.markus...@gmail.com> wrote:
>>> Is there any recommended location for Fortran '.mod' files, when
>>> installing a Fortran library? The library itself should go into 'lib'
>>> (the .a or .so files).
>
> Not really.
>
>>> Any recommendations? Common practice?
>
> I think a common practice for Linux distributions is to place them in /
> usr/include, which is admittedly not the best place. For "mpif90" one
> has the advantage that there is a wrapper - thus they can be placed in
> specific directories.
>
> If one has one own's library, one simply uses the /usr/local/mylib/
> $version/$compiler/{include,module,whatever} directory for the module
> file - by specifying the directory as search path.
>
>> I would say that the lib directory is a good choice, since, as you
>> point out, these files are specific to the platform.
>
> I think that position is worse than /usr/include; while the latter is
> in the search path, /usr/lib{32,64} etc. is not. Additionally, it does
> not solve the problem of the compiler (version) dependence.
Well, at least platform-specific lib (sub)directories are allowed,
unlike include. As far as I understand the Unix (Gnu) standards. It
would be great to have some place automatically in the search path, however.
> (Side note: I think the Cray ftn compiler by default embeds the module
> information in the .o and thus in the .a files, avoiding the need
> for .mod files.)
We're using libtool to generate/manage the libraries, including shared
objects. I don't know what this means on the Cray. Not that I ever had
access to one ...
>
> Jakub Jelinek (of Red Hat) suggested once that one should use
> something like /usr/{local,}/include/finclude/
> <compiler,target,version> such as /usr/{,local/}include/x86_64-unknown-
> linux-gnu/4.7.0/ -- and make the compiler automatically search in
> those directories. One could also argue that the name should be /usr/
> {local/,}/lib/finclude instead.
>
> However, such a patch has not been written for gfortran - and I think
> other vendors have also not done steps into that direction. But I
> agree that it makes sense to think about that.
That's interesting information. So far, I'm inclined to choose a subdir
of lib rather than include, as said before, but I'm open to better
suggestions. It looks like 'modern' Fortran libraries are rarely
installed on a system (in the proper sense).
Maybe some reasonable choice could be implemented in Autotools, so
libtool cares for the search paths. But this is not done quickly, I admit.
> (Another thing I was thinking about was on-the-fly generation of .mod
> files: If the .mod file couldn't be found for "USE module", the
> compiler searches for the "module.f90" files (e.g. in only some
> directories like /usr/{local/,}include/finclude/) and automatically
> compiles it to generate a .mod file (and no assembler/object file). I
> think that would be in the spirit of the standard where the Fortran
> module (source file) is the authoritative source, which is compiler
> independent. For that, submodules would be also handy. I do not see
> that happening soon, however.)
>
> Tobias
This would require the complete source tree, and compiling in correct
order, resolving dependencies, requires a Makefile -- even if only .mod
files are generated.
Paul Anton Letnes
I hve been wondering about this, too. Especially, how does one tackle
compiler differences? E.g. gfortran .mod files are not even compatible
between minor versions (4.3 vs. 4.4 etc). Should one make .mod files for
all compiler versions? And what if you are distributing a library which
depends on another library; how do you ensure that the .mod files for
the library you depend on are available for the exact compiler version
you are using?
Paul
Carlie Coats
Well, mine are too complicated for "automake" to handle well --
multiple compiler-flag-dependent builds on each platform, for
example -- but if you use a common build-directory for the
hierarchy (with "VPATH=${SRCDIR}:${OBJDIR}") and proper
dependencies between the hierarchy-branches, it should work.
-- Carlie
Ron Shepard
Carlie Coats <car...@jyarborough.com> wrote:
I have found it acceptable to ignore the .mod file dependencies
entirely in the makefile. In my codes, all of the compilation is
triggered entirely on the *.o files. The *.mod files are created at
the same time, of course, there are several differences in the two
that cause problems with make. The biggest, of course, is that a
single *.f90 file results in a single *.o file, but a single *.f90
file can result in multiple *.mod files. For a while, the extension
.mod was not standardized, or in some cases a compiler might not
even create a .mod file. These days it seems like most compilers
use the same filename conventions, but once bit always wary.
So with this approach, you end up with dependencies like
file1.o: file2.O file3.o file4.o
Of course, that is not really the dependency that you are trying to
describe. What you are really saying is that file1.o depends on
some modules that are created as the same time as those object
files. But make does the same thing in either case, so if you can
avoid all of the complications related to .mod files this way, IMO
that is an acceptable plan.
$.02 -Ron Shepard
jfh
> On May 3, 9:44 am, Arjen Markus <arjen.markus...@gmail.com> wrote:
>
> > > Is there any recommended location for Fortran '.mod' files, when
> > > installing a Fortran library? The library itself should go into 'lib'
> > > (the .a or .so files).
>
> Not really.
>
> > > Any recommendations? Common practice?
>
> I think a common practice for Linux distributions is to place them in /
> usr/include, which is admittedly not the best place. For "mpif90" one
> has the advantage that there is a wrapper - thus they can be placed in
> specific directories.
>
> If one has one own's library, one simply uses the /usr/local/mylib/
> $version/$compiler/{include,module,whatever} directory for the module
> file - by specifying the directory as search path.
Some of us work with Linux systems where ordinary users may not place
things in /usr/include. What is the best thing for us to do?
-- John Harper
fj
In that case, I leave modules, libraries and executables in the building
directory which name depends on the compiler suite and the architecture.
Object files are usually put in sub directories of that building directory :
software
-> source
-> part1 -> *.f *.f90 *.c *.h
-> part2 -> *.f *.f90 *.c *.h
-> bin
-> linux_64-intel
-> *.mod *.a *.exe
-> part1 -> *.o
-> part2 -> *.o
-> windows-gcc
-> *.mod *.a *.exe
-> part1 -> *.o
-> part2 -> *.o
>
> -- John Harper
--
François Jacq
Wolfgang Kilian
Same here, except that the dependencies are implemented for the .lo
files (libtool objects). And there is code in the Makefile.am that
automagically creates these dependencies from the Fortran sources. If
anybody is interested, here is the snippet:
## Fortran module dependencies
# The following line just says
# include Makefile.depend
# but in a portable fashion (depending on automake's AM_MAKE_INCLUDE
@am__include@ @am__...@Makefile.depend@am__quote@
Makefile.depend: $(libwhizard_core_la_SOURCES) $(libwhizard_main_la_SOURCES)
@rm -f $@
for src in $^; do \
module="`basename $$src | sed 's/\.f[90][0358]//'`"; \
grep '^ *use ' $$src \
| grep -v '!NODEP!' \
| sed -e 's/^ *use */'$$module'.lo: /' \
-e 's/, *only:.*//' \
-e 's/, *&//' \
-e 's/, *.*=>.*//' \
-e 's/$$/.lo/' ; \
done > $@
DISTCLEANFILES = Makefile.depend
> Of course, that is not really the dependency that you are trying to
> describe. What you are really saying is that file1.o depends on
> some modules that are created as the same time as those object
> files. But make does the same thing in either case, so if you can
> avoid all of the complications related to .mod files this way, IMO
> that is an acceptable plan.
-- Wolfgang
Wolfgang Kilian
A straightforward approach is to use the --prefix option of configure
(cf. autoconf), so the builder of the package can specify a single
installation path. By default, this is /usr/local. This way, you are
equally prepared for a system installation (by the admin) and for a user
installation. I'd keep build and installation separate.
David W Noon
Hash: SHA1
On Tue, 3 May 2011 15:02:47 -0700 (PDT), jfh wrote about Re: Location
of .mod files?:
[snip]
>things in /usr/include. What is the best thing for us to do?
or /usr/local/include then I replicate 3 directories under my home
directory. Thus, I have:
~/bin
~/lib
~/include
I put my .mod files in ~/include, along with any other "copybooks", to
use the COBOL term.
- --
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply by e-mail.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk3BYxsACgkQ9MqaUJQw2MkgYACdGy0pA1gK8lqx0vO2x8qYO6Xk
ZxAAoKI1gJ5iCoqgN/hQi/XaYSO24WyN
=GcH0
-----END PGP SIGNATURE-----