warnings: check -Wfoo rather than -Wno-foo
authorEric Blake <eblake@redhat.com>
Wed, 14 Aug 2013 23:02:58 +0000 (17:02 -0600)
committerEric Blake <eblake@redhat.com>
Thu, 15 Aug 2013 19:39:28 +0000 (13:39 -0600)
commit826b63b6827fb4477550974ef7bfb4a81135e34f
tree4ba30e018bc31b73225aaec3ab38dcd101d98f06
parent1c77dbc8b155f2667242e560601ab1ec913a78af
warnings: check -Wfoo rather than -Wno-foo

As reported by Christophe Fergeau and others, use of the
warnings modules is awkward when probing for negative
warning flags.  For example, clang recognizes
-Wno-unused-command-line-argument, but gcc does not;
gcc silently ignores unknown warnings in isolation, but when
something else also causes a compilation problem, gcc then
compounds the overall message by also complaining about the
unrecongized command line option at that time.  The gcc manual
documents that this behavior is intentional so that someone
can add a -Wno-foo silencer to CFLAGS for a warning that older
gcc does not understand, and where the warning is undesired
under newer gcc; it also documents that probing for the -Wfoo
positive form of the error is a reliable way to tell if the
negative form will actually suppress anything.  Clang will
warn for both positive and negative forms of an unknown
option.

Since common usage includes:

for w in $list; do
  gl_WARN_ADD([$w])
done

the solution must be polymorphic to work on both m4 literals
and shell variables (similar to AS_VAR_SET polymorphism).

* m4/warnings.m4 (gl_COMPILER_OPTION_IF): If name begins with
-Wno-, test if the compiler recognizes the positive form instead.

Signed-off-by: Eric Blake <eblake@redhat.com>
ChangeLog
m4/warnings.m4