Peter Shenkin wrote:

> Let's also point out, however, that a big problem for F90 is
> that, in general, the .o files of the USEing procedures have
> to depend on the .o files containing the MODULEs.  There's really
> no other portable way to write Makefiles.

I usually have them depending on <source-file-in-upper-case>.mod or
<source-file-in-upper-case>.kmd, depending on the platform, which
is more correct but a substantial portability problem.

> However, this causes
> many unneeded compilations, since, really, it should only be
> necessary to recompile the .o file of a USEing procedure when
> the *interface* to a MODULE changes.
> 
> This is one way in which F90 is greatly inferior to C,
> which mandates making interfaces visible by means of explicit
> inclusion of ascii files, usually called .h.  If the .h file
> doesn't change, the .o files that use it don't have to change.
> 
> The lack of this facility in Fortran no only causes extraneous
> compilations (making a rebuild last an hour instead of a minute,
> for example), but also makes it very difficult to encode the re-use
> of compiled libraries and the associated dependencies in Makefiles
> in a platform-dependent way.

In ftp://ftp.ncsa.uiuc.edu/x3j3/doc/year/98/98-104.ps.gz and
.../98-125.ps.gz I proposed a way to reduce the compilation cascade
problem.  I gave a presentation at J3 meeting 144.  It was
sympathetically received, but none of the champions of existing
work items jumped up and said "I really need that!  My work can't
proceed without it!"  As a consequence, it didn't get added to
the work plan.  To be fair to all the other proposals for changes
to Fortran, it would only be appropriate to add it if all the
other proposals that didn't have high enough priority to get into
the work plan were reconsidered, too.  We don't have time for
that, and even if we did, we don't have much slack (if any) to
take on additional work items.

Some compiler vendors are, however, implementing a useful half-measure:
After compiling a module, the proposed new .mod file is compared to
the existing one.  If it's identical -- presumably because none of
the module's interface is changed -- the old one isn't replaced.  This
prevents a compilation cascade, but that module is nonetheless re-compiled
at every make, because its .mod file is forever out-of-date with respect
to its corresponding .f90 file.  Eventually, when everything is being
re-compiled at every make, if one runs a make with the compiler option
that says "Write a new .mod file even if it's identical to the old one"
the cycle starts anew.

Van Snyder


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%