RFC: Big Makefile patch for WARNS settings

[Ulrich Spörlein]

Hi Doug,

On Mon, 12.10.2009 at 16:49:47 -0700, Doug Barton wrote:
> Ulrich Spörlein wrote:
> > Dear -hackers,
> > 
> > I would like you to give me your thoughts on the attached patch. There
> > are no functional changes, what I'm trying to do is introduce WARNS?=6
> > for all top-level Makefiles and override that on a subdir basis.
> > 
> > Why the churn? Because I think it sticks out more, if there's a WARNS=0
> > in your Makefile rather than the default being WARNS=0. Perhaps this
> > gets more incentive going for fixing these WARNS.
> 
> I don't see how this provides an incentive at all.
> 
> I also object to this change on the grounds that down the road
> debugging is potentially going to be more difficult when someone
> forgets that there is a default WARNS level of 6.

The "default" would be the setting inherited by, eg,
src/bin/Makefile.inc. This already has a WARNS=6, are you saying that
debugging stuff under bin/ has been made more difficult by that change?
Why do we want bin/ to be WARNS-clean and not care about usr.bin/?

To make things clear, no changes will be made to /usr/share/mk, if
that's what you are afraid if. Unless you do ".include ../Makefile.inc"
somewhere under src/*, you won't get WARNS at all.

> One of the strengths of the BSD-style make is the amount of routine
> stuff that goes on behind the scenes to make it easier to write good
> makefiles. However I don't think this should be one of those things.

One of the strengths of BSD in general that I have come to love is its
higher consistency compared to most other systems. With WARNS=6 under
bin/ and WARNS=2 under sbin/ this consistency is violated.
 
> > There's also a lot of
> > work done by the DragonflyBSD folks which I intend to port peu a peu.
> 
> Can you elaborate on this? What work are you planning to port over,
> and how does it depend on this default WARNS level issue?

See
http://gitweb.dragonflybsd.org/dragonfly.git?a=search&h=HEAD&st=commit&s=WARNS6

It depends in no way on the included WARNS level, but "the big switch"
needs to be done anyway, so why not upfront?

> > Note: There are lots of style changes for games/ and sbin/, which I can
> > seperate out for easier review. But I'd like to make some sweeping
> > patches to bring them more inline with style.Makefile(5)
> 
> Putting these two changes in the same patch is not a good thing. It
> makes it harder to read diffs, and commits that address separate
> issues should be done separately anyway.
> 
> That said, I think that the style-compliance issue is a valid one, and
> I personally would be in favor of that happening after the
> 8.0-release, FWIW.

I will separate those changes out and work some more on them on another
branch. I would really like to get the WARNS changes in first though.

Thanks for all the comments,
Uli