RFC: Big Makefile patch for WARNS settings

Ulrich Spörlein uqs at spoerlein.net
Tue Oct 13 07:04:20 UTC 2009

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?


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,

More information about the freebsd-hackers mailing list