On Tue Dec 27 11, Philip Paeps wrote: > On 2011-12-26 10:10:40 (+0000), Alexander Best <arundel_at_freebsd.org> wrote: > > 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=. > > Wouldn't it be better to set WARNS=x rather than WERROR=? WERROR= says "this > code has bugs, it breaks tinderbox" whereas WARNS=x says "this code has the > following kind of bugs which break tinderbox". > > Possibly wrapped in an architecture-test where appropriate. well there are a few issues here: 1) Jan Beich informed me via a private email that enclosing WERROR in arch specific conditions is a bad idea. if the code gets ported to a new architecture WERROR doesn't get set and so for every new architecture one has to evaluate again, whether WERROR needs to be set or not. so i'm inclined to agree with dim_at_ that we should not add architecture specific conditions -- however i think adding compiler specific conditions is a good idea. 2) the problem with settings WARNS= or specific -Wno-X or -Wno-error=X is that expecially GCC doesn't have specific -WX flags for certain warnings. some warnings are implied by -Wall and cannot be turned off seperately. so in order to get rid of these warnings (which are being handled as errors), we would need to disable -Wall. and i think setting WERROR= in order to handle all warnings for specific code as warnings rather than as errors is the better solution. i've reworked the patch to only remove WERROR=, where it is not needed anymore for any supported arch, or where it can be wrapped in a compiler condition. cheers. alex > > - Philip > > -- > Philip Paeps > Senior Reality Engineer > Ministry of Information
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC