cvs commit: src Makefile.inc1 src/share/mk bsd.compat.mk

[Ruslan Ermilov]

On Mon, Feb 28, 2005 at 10:26:18AM -0800, David O'Brien wrote:
> On Mon, Feb 28, 2005 at 11:36:22AM +0200, Ruslan Ermilov wrote:
> > On Mon, Feb 28, 2005 at 11:34:14AM +0200, Ruslan Ermilov wrote:
> > > On Mon, Feb 28, 2005 at 09:23:38AM +0000, David E. O'Brien wrote:
> > > > obrien      2005-02-28 09:23:38 UTC
> > > > 
> > > >   FreeBSD src repository
> > > > 
> > > >   Modified files:
> > > >     .                    Makefile.inc1 
> > > >     share/mk             bsd.compat.mk 
> > > >   Log:
> > > >   Accept the old user interface for NO_CLEAN as it is a POLA violation as
> > > >   we've eventually changed the user interface of a common command.
> > > >   
> > > >   Revision  Changes    Path
> > > >   1.486     +3 -0      src/Makefile.inc1
> > > >   1.19      +0 -1      src/share/mk/bsd.compat.mk
> > > > 
> > > Why did you do this?  bsd.compat.mk already handled this, and
> > > Makefile.inc1 is always called with ``-m /usr/src/share/mk''.
> > > Even if you call Makefile.inc1 directly, and your /usr/share/mk
> > > is up-to-date, you'll get a warning and setting.  Would you
> > > please revert this change?
> > > 
> > Or maybe I misunderstood you, and you just wanted it to be quiet?
> > Even so, please handle it all in bsd.compat.mk.
> 
> Looking at bsd.compat.mk, especially with "BURN_BRIDGES" in there; I'd
> like to ask you for a patch you'd be happy with that isn't going away in
> a few months when the bridges burn.  A correct patch will have to add
> another layer of .if statements in the case of "NOCLEAN".
>  
First tell me what you were trying to achieve with this change,
as I cannot intuit it from your commit log, and you don't tell
me.  :-)

Let me explain.  "make ... -DNOCLEAN" worked before it, replacing
it with NO_CLEAN and giving an annoying warning, so burning bridges
later won't be a surprise.  If you thought it wasn't working, then
please re-test and consider reverting your change.

If you are just hiding the warning, can you explain your reasoning,
as in my opinion it just kills the idea of "deprecation".  People
will continue to use it, without letting us remove it safely later.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20050228/4d4438ec/attachment.bin