svn commit: r201227 - in head: sbin/comcontrol sbin/mount sbin/mount_msdosfs sbin/mount_nullfs sbin/rcorder usr.bin/find usr.bin/gencat usr.bin/mklocale usr.sbin/config usr.sbin/cpucontrol usr.sbin...

[Xin LI]

On Tue, Dec 29, 2009 at 10:40 PM, Ed Schouten <ed at 80386.nl> wrote:
> * Xin LI <delphij at gmail.com> wrote:
>> On Tue, Dec 29, 2009 at 10:22 PM, Ed Schouten <ed at 80386.nl> wrote:
>> > Hi Gabor,
>> >
>> > * Gabor Kovesdan <gabor at FreeBSD.org> wrote:
>> >> I wonder if it would be worth to invent a WARNS=7 level, which would
>> >> be WARNS=6 + ANSI. Although ANSI-conformance isn't a -Wfoo flag,
>> >> which is WARNS for but conforming ANSI means a higher level
>> >> cleannes, which is demanded, so I think it wouldn't really
>> >> contradict to the semantics of WARNS.
>> >
>> > So far I've been using -Wold-style-definition, which I've been using
>> > make these changes. I am planning on just adding that to WARNS=6,
>> > considering that almost all the code at WARNS=6 builds with this flag
>> > enabled now.
>> >
>> > I'd rather not add a WARNS=7, because then I'm afraid almost nobody will
>> > know about its existence, causing it to be mostly ignored. In an ideal
>> > world, I think we should get rid of WARNS. We could just enable all -W
>> > flags by default, except -Werror. That way people would be invited to
>> > fix the warnings over time.
>>
>> Probably leaving -Werror by default is better...  Without -Werror I
>> think there is fewer chance that these issues being noticed.  The
>> point of having -Werror is that it means a build break (at the
>> developers' local machine, or tinderbox if he or she didn't do a full
>> universe build), loud enough and can be fixed early rather than
>> letting them go.  Historically we only disable -Werror when major
>> compiler change, etc.
>
> Sure. We should just enable it in Makefile.inc by default, but basically
> my proposal is to just reduce the entire warnings thing to just two
> options:
>
> - Have all warnings enabled, but not -Werror.
> - Have all warnings enabled and also -Werror.
>
> Where we enable the latter is another discussion.

Oh...  There are a lot of contributed code that can not even pass
WARNS=1 :)  Also there are some code "for historical reasons" must
cast off qualifiers, etc., currently our build system have warning
levels assigned at module level, which could be inconvenient for this
policy to be effective (e.g. a 100-files module with 95 files WARNS=6
clean and 5 rest are only WARNS=4 clean, we can use WARNS=4 and
WERROR=1 to make sure that no file would get worse, but with WARNS===6
and WERROR either 1 or 0, we could lose the ability to limit the bit
rot, except we convert all these 5 files as a wholesale :)

> (Almost happy new year),

Happy new year!

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net