kent@happym.UUCP (Kent Forschmiedt) (10/29/88)
Make did a very evil thing. I had created a circular dependency in my makefile, and was using make -d to find it. A condensed version, showing my mistake, follows. There are about 35 object files in the library that it was building. There is an odd rule for one of the objects, because part of its source is generated by another program. I had accidentally made the program dependent on the library, thus creating the circle. In the context of the example below, $(LIB)(file1.o) was not up to date realtive to s.file1.c, and $(LIB)(file2.o) was up to date. I was watching it go, using ^S/^Q to stop and start it, until I found the problem, then hit ^C (DEL, for purists) to stop it. I couldn't see what it was doing when I did that, since ^C flushes the tty output buffer. It said "*** s.file2.c removed ***" !!! And it was true! LIBOBJ = $(LIB)(file1.o) $(LIB)(file2.o) # file1.c #includes x.i $(LIB)(file1.o): file1.c funnycmd funnycmd >x.i $(CC) -c $(CFLAGS) file1.c ar rv $(LIB) file1.o rm -f file1.o funnycmd: $(LIB) .c.a: $(LINT) $(LINTFLAGS) -u -lm -Ldb -c $< $(CC) $(CFLAGS) -c $< ar rv $@ $*.o rm -f $*.o .c~.a: $(GET) $(GFLAGS) -p $< > $*.c $(LINT) $(LINTFLAGS) -u -lm -Ldb -c $*.c $(CC) -c $(CFLAGS) $*.c ar rv $@ $*.o rm -f $*.[co] -- kent@happym.UUCP, tikal!camco!happym!kent, Happy Man Corp. USA 206-282-9598
kent@happym.UUCP (Kent Forschmiedt) (10/29/88)
Re my previous posting and my system: This system is Motorola V/68 R2V3.0. -- kent@happym.UUCP, tikal!camco!happym!kent, Happy Man Corp. USA 206-282-9598
alex@umbc3.UMD.EDU (Alex S. Crain) (11/01/88)
In article <556@happym.UUCP> kent@happym.UUCP (Kent Forschmiedt) writes:
[discription of how make(1) eats a depencency]
I have seen this happen under SCO Xenix, AT&T unix-pc-unix-3.51, AT&T Sys5r2
on an Opus card....
If you interrupt make at just the right moment, it will eat the file
that its compiling (???.c) as opposed to the half created output file (???.o).
I can't reproduce it, but its happened enough times to convince *me* that its
a valid bug.
--
:alex.
Systems Programmer
nerwin!alex@umbc3.umd.edu UMBC
alex@umbc3.umd.educhris@cetia.UUCP (Chris Bertin) (11/06/88)
In article <555@happym.UUCP>, kent@happym.UUCP (Kent Forschmiedt) writes: > I was watching it go, using ^S/^Q to stop and start it, until I found > the problem, then hit ^C (DEL, for purists) to stop it. I couldn't see > what it was doing when I did that, since ^C flushes the tty output > buffer. > > It said "*** s.file2.c removed ***" !!! > > And it was true! The same thing happened to me several years ago. I didn't want to chase the bug, so I edited main.c and added: && !sdot(p) to the list of removal conditions in the intrupt() routine. For those without sources, 'sdot(p)' checks if 'p' is an 's.' file. I wonder how many flames will cross the Atlantic... -:) Chris -- Chris Bertin | CETIA | 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France Ext: 239 | inria!cetia