Re: MAKE_JOBS_SAFE=[number]

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Thu, Oct 04, 2012 at 08:15:49AM +0200, Marc Espie wrote:
 > >> Actually, yacc runs are often a problem. A lot of people out there do not
 > >> understand make, and they think that:
 > >> 
 > >> file.c file.h:    file.y
 > >>   some yacc rule
 > >> 
 > >> is going to work.
 > >> 
 > >> Not so, since that expands to two separate targets, and yacc may very
 > >> well be generating file.c while file.h is being used elsewhere. Oops.
 > > 
 > > This issue is the subject of periodic flamewars, because even though
 > > the label on bmake's koolaid packets says what you've described, the
 > > historical and traditional make behavior is that what you've cited is
 > > in fact a correct yacc rule.
 > 
 > Well, posix says so. Go fix posix.

C&V?

The non-parallel behavior has always been that make checks what got
changed after running a recipe and adjusts what it does next
accordingly. This is true not only of historical SVR4 make but also of
gmake and all versions of BSD make I've ever seen.

If you want to write makefiles that work, you need to do things like

all:
        $(MAKE) genfiles
        $(MAKE) realall

depend:
        $(MAKE) genfiles
        $(MAKE) realdepend

genfiles:
        $(YACC) -d parser.y ...

realall: $(PROG) ...

realdepend:
        $(MKDEP) $(SRCS) ...

because your makefile might end up running in gmake (or worse) and
there's no other way. Except for explicitly not supporting parallel
builds. (Remember also that it's not safe to modify files that aren't
on the LHS of the rule.)

The interesting question is what you ought to be allowed to assume if
you're using a nondysfunctional make.

-- 
David A. Holland
dholland%netbsd.org@localhost