Simon Josefsson wrote on 2008-11-18:
> I'm trying to force gradual automation of it by making it a two-step
> simple process: 1) Sync the list of all warnings with latest GCC
> manual. 2) Re-compile and add exceptions for the new warning variables,
> and if optionally human time is available, review and modify the source
> code.
Thanks for explaining.
Brian Dessent wrote on 2008-11-18:
> Also, while on the topic of warning control, you might be interested in
> -fdiagnostics-show-option which is available in 4.1+ and causes gcc to
> augment each diagnostic message with the name of the -W option that
> controls that message (at least for those that have a corresponding
> option.)
Having heard no announcement of Simon's blog so far, I'm adding a summary
of these discussions as documentation. Feel free to extend it, of course.
2008-12-06 Bruno Haible <[EMAIL PROTECTED]>
Document the 'manywarnings' module.
* doc/manywarnings.texi: New file.
* doc/gnulib.texi: Include it.
*** doc/gnulib.texi.orig 2008-12-06 12:07:20.000000000 +0100
--- doc/gnulib.texi 2008-12-06 11:22:05.000000000 +0100
***************
*** 5757,5762 ****
--- 5757,5763 ----
* Supporting Relocation::
* func::
* warnings::
+ * manywarnings::
@end menu
@node alloca
***************
*** 5840,5845 ****
--- 5841,5848 ----
@include warnings.texi
+ @include manywarnings.texi
+
@node GNU Free Documentation License
@appendix GNU Free Documentation License
================================ doc/manywarnings.texi ========================
@node manywarnings
@section manywarnings
The @code{manywarnings} module allows you to enable as many GCC warnings as
possible for your package. The purpose is to protect against introducing new
code that triggers warning that weren't already triggered by the existing code
base.
An example use of the module is as follows:
@smallexample
gl_MANYWARN_ALL_GCC([warnings])
# Set up the list of the pointless, undesired warnings.
nw=
nw="$nw -Wsystem-headers" # Don't let system headers trigger warnings
nw="$nw -Wundef" # All compiler preprocessors support #if UNDEF
nw="$nw -Wtraditional" # All compilers nowadays support ANSI C
nw="$nw -Wconversion" # These warnings usually don't point to
mistakes.
nw="$nw -Wsign-conversion" # Likewise.
# Enable all GCC warnings not in this list.
gl_MANYWARN_COMPLEMENT[warnings], [$warnings], [$nw])
for w in $warnings; do
gl_WARN_ADD([$w])
done
@end smallexample
This module is meant to be used by developers who are not very experienced
regarding the various GCC warning option. In the beginning you will set the
list of undesired warnings (@samp{nw} in the example above) to empty, and
compile the package with all possible warnings enabled. The GCC option
@code{-fdiagnostics-show-option}, available in GCC 4.1 or newer, helps
understanding which warnings is originated from which option. Then you will
go through the list of warnings. You will likely deactivate warnings that
occur often and don't point to mistakes in the code, by adding them to the
@samp{nw} variable, then reconfiguring and recompiling. When warnings point
to real mistakes and bugs in the code, you will of course not disable
them.
There are also many GCC warning options which usually don't point to mistakes
in the code; these warnings enforce a certain programming style. It is a
project management decision whether you want your code to follow any of these
styles. Note that some of these programming styles are conflicting. You
cannot have them all; you have to choose among them.
When a new version of GCC is released, you can add the new warning options
that it introduces into the @code{gl_MANYWARN_ALL_GCC} macro (and submit your
modification to the Gnulib maintainers :-)), and enjoy the benefits of the
new warnings, while adding the undesired ones to the @samp{nw} variable.
