Anthony Stone <[log in to unmask]> reports that he prevents unnecessary
compilation cascades by comparing an existing .mod file, if any, to
one that results from a compilation, and deletes the new one if they
are identical.
This breaks down if one inserts a dependency of the .mod file on the
.f90 file. I'm not sure, however, that it works reliably if one does
not insert the dependency.
Suppose one has the following dependency rules (I leave out the actions):
program: a.o b.o
a.o: a.f90 b.mod
b.o: b.f90
and suppose one changes b.f90. It is clear that "b.o" and "program"
will be reconstructed.
I don't know whether "make" analyzes the dependencies before hand, and
determines everything to do, or re-analyzes them after every action. If the
latter, then Stone's scheme works. If the former, and one changes "b.f90"
in such a way that "b.mod" becomes different from its former self, "a.o"
should be reconstructed, but the a priori analysis would not result in
doing so. Changing the last dependency to "b.o b.mod: b.f90" causes the
compilations to take place, and in the correct order. In the case that
"b.f90" is not changed, but that "b.mod" is out-of-date with respect to
"b.f90" (because after a previous compilation it was discovered that "b.mod"
had not changed), one unnecessarily compiles "a.f90" because of the chain
"program: a.o: b.mod: b.f90".
Does "make" work in the former or latter way?
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|