[rfc] removing/conditionalising WERROR= in Makefiles

From: Alexander Best <arundel_at_freebsd.org>
Date: Mon, 26 Dec 2011 10:10:40 +0000
hi there,

i grep'ed through src/sys and found several places where WERROR= was set in
order to get rid of the default -Werror setting. i tried to remove those
WERROR= overrides from any Makefile, where doing so did not break tinderbox.

in those cases, where it couldn't be completely removed, i added conditions to
only set WERROR= for the particular achitecture or compiler, where tinderbox
did not suceed without the WERROR=.

i talked to dim_at_ on #freebsd-clang_at_OFTC and he was against enclosing WERROR=
in a architecture or compiler condition. his statement was:

"
dim : I'm not going to riddle all those makefiles with endless comments, people
      have to learn to look in the commit history for a file.
"

however the problem is that most of the time the commit message by the person
who added WERROR= to a Makefile doesn't state *why* the person did it and most
importantly it doesn't state in *which* case tinderbox failed without the
WERROR= (see *).

so my suggestion would be that instead of setting WERROR= unconditionally in
Makefiles, it should be enclosed in a condition to only set it in a particular
case, where tinderbox *will* fail.

an example is r228861. here dim_at_ set WERROR= in sys/modules/nve/Makefile
unconditionally. however tinderbox will only fail when

A) clang is used as compiler
B) when building for i386

these facts aren't clear from the commit message. so i'd suggest (please see
the attached patch) to conditionalise such settings.

another point i'd like to make is that WERROR= might have been set in a
Makefile in the past to unbreak tinderbox for a certain arch that is no longer
supported. since most of the time the commit logs simply state something like:

*)
"...remove -Werror for now to unbreak tinderbox..."

nobody will notice that after support for a certain arch was removed, the
WERROR= line can be removed from that particular Makefile.

that's why i'd like to propose the following patch. i ran a full tinderbox run
against r228878 and it suceeded.

cheers.
alex

Received on Mon Dec 26 2011 - 09:10:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC