On Thu, 27 Nov 1997, Malcolm Cohen wrote:

> Dr W.W. Schulz said:
> > Thinking about it I have come to like to .M scheme more and more WITHIN
> > the constraints of current F90/95/2000 standards (or drafts). And
> > it would to some extent lessen the compilation cascade,
> > i.e. recompiling many dependent routines that USE a module though the
> > used module's interface has not changed.
> > My idea is a bit clumsy but could do the job.
> > USEing a module makes another routine dependent on the used Module's
> > interface but not its object file (.o). In the .M scheme one can do
> > the following:
> >   compile the file with one or more modules
> >   compare the new .M with the old .M file
> > 	  if different replace (.M has new timestamp,
> > 				the interface has changed)
> >           else leave old .M file with old timestamp
> >   <file>.f90 depends on <others>.M, and of course, on its own <file>.o
> 
> I don't see how this helps - if a source file contains many modules, updating
> one which causes the .M file to change will cause unnecessary compilations.
> Whereas with the same scheme applied to .mod files, only those files which
> use the module that changed will be recompiled.
The objection to many modules per file is right. But it can easily be
avoided by the programmer by putting each module in a separate file.
> 
> (And if a source file contains only one module, there is effectively no
> difference between the .M and .mod schemes).

There is one important one at least in context of using make:
the .M scheme uses the filename, .mod the module name to name
the .M or .mod file respectively. Agreed, the user could choose the
same module name as the filename. But some compilers do change upper/lower
cases etc. (e.g. SGI's f90 compiler does)

> > This should work quite well with makefiles.
> Unfortunately not; since the module.M file depends on the module.f90
> file,
Yes but only with respect to the interface that is visible and USEd 
by others.

> module.f90 will be recompiled every time
Why? module.f90 is recompiled only if module.o is older.
module.f90 itself does not depend on module.M.

>(and the new module.M compared with the old module.M, found to be the
> same etc.).
No, no. module.M gets a new timestamp only if the interface gets changed.
Then make will see that module.M stayed old and the files that depend on
module.M will not be recompiled whereas at the moment they do since in the
.mod scheme make must check for .o files.
To give an example for make:

# The suffix rules in make will be the same as now:
.f90.o:
	$(F90) $(F90FLAGS) -c $<

# code in B.f90 uses A.f90's module MODULE A:
B.o: A.M    # usually we have A.o here

B gets recompiled if B.f90 is younger or if A.M is younger
but it doesn't depend on A.o anymore as is standard make practice.

This approach is at least a relief from some cascade even though it
doesn't solve all the problems. But within the given constraints
it is useful. Neither make nor Fortran(2000) will be changed soon
enough to provide a solution in the near future.

> Basically the problem is that make is not quite intelligent enough to
> do this particular job.  According to one's disposition one can either
> (1) put up with the compilation cascade
> (2) use external procedures and just put the data types and interfaces
>     into modules
> (3) add intelligence to make (or use a different tool)
> (4) split modules into "specification" and "implementation" parts so
>     you can change the implementation part separately
> 
> Each of these has advantages and disadvantages which have been
> discussed at length before, so I will pass over them silently except
> to note that there are timing considerations - only options (1) and
> (2) can be done immediately, option (3) requires some work to be done
> (anyone want to hack gnumake?) and option (4) requires waiting at
> least 5 years for F2002, even assuming WG5 can be sold on it.
> 
> Alternatively, if someone has some brilliant idea which 'make' will
> understand, I would be very pleased to hear it!  (But no-one managed
> to come up with one last time).

Regards,
Werner
-----------------------------------------------------------------------
| Werner W Schulz                                                     |
| Dept of Chemistry                  email:     [log in to unmask]       |
| University of Cambridge            Phone:     (+44) (0)1223 336 502 |
| Lensfield Road                     Secretary:          1223 336 338 |
| Cambridge CB2 1EW                  Fax:                1223 336 536 |
| United Kingdom                     WWW:                             |
-----------------------------------------------------------------------



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