Subject: bin/2749: [dM] make is obnoxiously stupid about loops
To: None <gnats-bugs@gnats.netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: netbsd-bugs
Date: 09/12/1996 19:21:52
>Number:         2749
>Category:       bin
>Synopsis:       [dM] make is obnoxiously stupid about loops
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 12 16:35:01 1996
>Last-Modified:
>Originator:     der Mouse
>Organization:
	Dis-
>Release:        1.2_BETA
>Environment:
	Any (seen on Sun-3/260)
>Description:
	make gratuitously complains about loops in its dependency graph
	in cases when there's really no excuse for it.  Specifically,
	when considers a loop involving (a) an explicitly stated
	derivation and (b) a derivation based on a suffix rule to be a
	fatal problem.  It seems to me that suffix rules should be used
	only when and to the extent that they must be.
>How-To-Repeat:

	% cat Makefile
	foo: foo.bar.o
		$(CC) -o foo foo.bar.o
	
	foo.bar.c: foo.bar
		do-something < foo.bar > foo.bar.c
	% touch foo.bar
	% rm -f foo foo.bar.o foo.bar.c
	% make
	Graph cycles through foo.bar.c
	
	`foo' not remade because of errors.
	% 

	I actually ran into this with a language processor that
	generated C code.  If "bar" is the name for the language, the
	above Makefile would be close to a real example - foo.bar is
	the "bar" source and foo.bar.c is the generated C file.  (There
	is a strong argument that foo.bar-c would make more sense for
	the generated filename, and indeed in the particular case of
	generating C code under NetBSD, one can use -x to force gcc to
	take the file as C code in spite of the unrecognized extension;
	however, this does not address the general problem.)

>Fix:
	The only fix I know of is to use an older make.  Berkeley make
	of 1981 vintage ("@(#)ident.c     4.1 (Berkeley) 81/02/28")
	does not suffer from this problem.  One SunOS release's (3.5, I
	think) has a make that produces a cryptic noise message ("$!
	nulled, predecessor circle") and is otherwise well-behaved.
	More recent Sun makes have the same problem the NetBSD make
	does.  I don't have much experience with other vendor makes in
	this respect.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D
>Audit-Trail:
>Unformatted: