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