maine@elxsi.dfrf.nasa.gov (Richard Maine) (12/06/89)
I am puzzled by one aspect of GNU make's behavior with intermediate
files in chains of implicit rules. It looks like a bug to me,
but I'll admit to being unfamilliar enough with all of this to
be unsure that this behavior was not somehow intended.
Oh yes, this is version 3.57 of GNU make, downloaded directly
from prep. I first ran into it when trying a port to Elxsi Embos,
but then found the same behavior with the unmodified code on
a Sun 3/60 running SunOs 4.0.3.
The relevant line of code is near the end of update_file_1, where
it sets must_make to 1 if any of the dependencies do not exist.
It seems to me that if file x is implicitly dependent on the
intermediate file x.o, which is implicitly dependent on x.f,
then there is no need to remake x just because x.o does not
exist, as long as x.f is older. This comes up naturally if
you don't have a short-cut rule for making x.f into x
(as was the case for the Embos port I was initially trying).
Even if it is decided that x should be remade in such a case,
this line comes after the code in intermediate files are
remade. Thus, make attempts to remake x because x.o is missing,
but it does not first remake the x.o, so the attempt to remake
x fails.
The result of this is that all is fine as long as x really needs to
be made (because it doesn't exist) or remade (because x.f has
changed). In those cases, x.o will get made, followed by x
(and then x.o will be deleted as an intermediate file). However,
if you do 2 'make x' commands in a row, the second one always
fails.
For a trivial example, use the following GNUmakefile, which just
declares 2 rules.
.SUFFIXES: .f .o
.f.o:
f77 -c $^
.o:
f77 $^ -o $@
Take any trivial "Hello world" fortran program like
program hello
write (*,*) 'Hello world.'
end
as an x.f file. Then do
make -r x
The -r is required to get rid of the default shortcut rules
and use only the 2 in the makefile. This works.
Then repeat the same make and it will fail.
I'm tempted to "fix" this by just deleting the questioned line
in the code, but it looks very intentional, complete with a comment.
This makes me think I might be missing the point.
Feedback?
--
Richard Maine
maine@elxsi.dfrf.nasa.gov [130.134.1.1]mcgrath%paris.Berkeley.EDU@GINGER.BERKELEY.EDU (Roland McGrath) (12/06/89)
This was indeed a bug. I have since fixed it. Deleting that line is not the ideal fix, but it works. You should instead change it to test that the dep is not intermediate.