gst@WJH12.HARVARD.EDU (Gary S. Trujillo) (02/16/89)
I must be missing something here, but I can't help feeling that the gcc
Makefile is designed to recompile very nearly the entire universe whether
or not very much has been touched. It has been my recent experience that
if I do a "make -n" following a successful make, I get something like:
gcc -g -c expr.c
gcc -g -c stmt.c
gcc -g -c expmed.c
gcc -g -c explow.c
.
.
.
In looking at the Makefile, and having performed a few experiments, I have
been able to determine that the sequences that go as follows are what's
causing this behavior:
insn-config.h: stamp-config.h ;
stamp-config.h : md genconfig
./genconfig md > tmp-insn-config.h
./move-if-change tmp-insn-config.h insn-config.h
touch stamp-config.h
Now, to me, it looks as if this construction *guarantees* that the *.c
files will get compiled whether or not their corresponding *.o files
are out of date with respect to them. For example, for expr.c, we have:
expr.o : expr.c $(CONFIG_H) $(RTL_H) $(TREE_H) flags.h \
insn-flags.h insn-codes.h expr.h insn-config.h recog.h
Since expr.o depends upon, among other things, insn-config.h, which, in
turn, depends on stamp-config.h, the re-creation of expr.o is triggered
if insn-config.h is older than stamp-config.h. However, it will *always*
be older, given that it is created by genconfig before the creation of
stamp-config.h. To prove this assertion, one has merely to re-run the
make after having deleted the rule-set in question (insn-config.h: ...).
I have found a quick work-around, though. If one does a "rm -f stamp-*.h"
followed by a manual linking of insn-*.h files with their corresponding
stamp-*.h files, it will fool make into accepting the insn-*.h files as
being up to date.
BTW, I'm using the standard System-V make on the AT&T 3B1 (UNIXpc).
Any ideas?
--
Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst
Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gstweening@Gang-of-Four.Stanford.EDU (Joe Weening) (02/16/89)
I saw the same behavior as you did with "make -n". (With both GNU make and the make on the system here.) But in this case, "make -n" doesn't report accurately what "make" will actually do. Don't ask me why; I'm not a make expert.