Subject: Re: NetBSD master CVS tree commits
To: Scott Reynolds <scottr@plexus.com>
From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
List: current-users
Date: 03/19/1996 19:11:31
[ COULD PEOPLE PLEASE NOT REPLY DIRECTLY TO SOURCE CHANGE MAIL?  send
  mail to the appropriate mailing list for discussion of the
  changes. ]

> What happens if the rules use a feature that's not present in the
> not-yet-upgraded make(1)?

"oh no!  what if somebody changes the the system libraries to require
a new version of lex or yacc to build?!"  (they're also built 'early'
in the 'make build' process.)

The answer is: you announce that fact, and be done with it.

How often do /usr/src Makefiles get changed to take advantage of
changes in bsd.*.mk?
	(Not very often.)

So, how often does this change to 'make build' win?
	(Not very often.)


How often do changes to system makefiles use a new feature of make?


I'd say "extremely infreqently," and when it happens, it's usually
accompanied by a change in other /usr/src Makefiles that rely on it.

So, i think this is, overall, likely to reduce lossage.


> This is a classic chicken-and-egg problem, but it seems to have been less 
> likely to cause brokenness the way it was...

I'd tend to disagree.  If people are using 'make build', they want to
see lossage as infrequently as possible, and i think that this would
reduce it.


Note that the correct solution is to completely fix the way that
builds happen, but that's another story.


cgd