Discussion:
manywarnings for C++
Reuben Thomas
2017-02-21 12:17:47 UTC
Permalink
I needed this recently, so I made it. I have not attempted to refactor the
code, as there seem to be multiple sensible-seeming ways to do this; I
attach a simple duplication of the manywarnings files, reconfigured for C++.
I'd be happy to work this up into a patch given some guidance on what
shape it should take.
​For example, would it be sensible to have a single spec file, with each
row as follows:

warning language-list comment

i.e. the first and third columns as at present, and the second giving the
languages for which the flag is used?
--
http://rrt.sc3d.org
Bruno Haible
2017-02-21 14:58:14 UTC
Permalink
Hi Reuben,

This looks reasonable: Since a project can use both gcc and g++ and since the
desired warning options for gcc and g++ are likely different, it's good to
have different macros, that set different variables (WARN_CFLAGS vs.
WARN_CXXFLAGS).
I'd be happy to work this up into a patch given some guidance on what shape
it should take.
In the current state, there is overlap between manywarnings.m4 and
manywarnings-cxx.m4 (macro gl_MANYWARN_COMPLEMENT defined twice).
Therefore I would leave gl_MANYWARN_COMPLEMENT defined only in manywarnings.m4,
and change modules/manywarnings-cxx to reference also m4/manywarnings.m4.

Going further, there is no real benefit of having manywarnings-cxx a different
module. Since an m4 macro that is not invoked does not contribute to the size
nor the execution time of the 'configure' script, I would just add the two
new macros gl_MANYWARN_ALL_GXX and gl_CXX_WARN_ADD - in manywarnings.m4
and warnings.m4, respectively.

However, two things are important:
- That the name of the *_cv_* variables are different in the C++ macro
than in the C macro.
- That you invoke AC_LANG_PUSH([C++]) at the beginning and AC_LANG_POP([C++])
at the end of the macro, so that AC_LANG_SOURCE invocations do the right
thing.

Please also fix the AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS]) invocation
in gl_WARN_ADD and gl_CXX_WARN_ADD. Since this macro expands to different
code after AC_LANG_PUSH([C++]) than after AC_LANG_PUSH([C]), it is wrong
to just AC_REQUIRE it. Needs to be a bit more intelligent.

Look at how _AC_LANG_ABBREV and _AC_LANG_PREFIX can be used. Maybe libtool.m4,
which also plays around with AC_LANG, gives you some hint about this.

Bruno
Reuben Thomas
2017-02-22 13:55:08 UTC
Permalink
Post by Bruno Haible
Hi Reuben,
This looks reasonable: Since a project can use both gcc and g++ and since the
desired warning options for gcc and g++ are likely different, it's good to
have different macros, that set different variables (WARN_CFLAGS vs.
WARN_CXXFLAGS).
​Thanks very much for the detailed guidance.​

Going further, there is no real benefit of having manywarnings-cxx a
Post by Bruno Haible
different
module. Since an m4 macro that is not invoked does not contribute to the size
nor the execution time of the 'configure' script, I would just add the two
new macros gl_MANYWARN_ALL_GXX and gl_CXX_WARN_ADD - in manywarnings.m4
and warnings.m4, respectively.
​Done.
Post by Bruno Haible
- That the name of the *_cv_* variables are different in the C++ macro
than in the C macro.
​Done.
Post by Bruno Haible
- That you invoke AC_LANG_PUSH([C++]) at the beginning and
AC_LANG_POP([C++])
at the end of the macro, so that AC_LANG_SOURCE invocations do the right
thing.
​Done, but do I also need to add an AC_LANG_PUSH/POP([C]) at the beginning
and end of gl_MANYWARN_ALL_GCC?​ If not, why not? (Is C assumed as the
default?)

Please also fix the AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS]) invocation
Post by Bruno Haible
in gl_WARN_ADD and gl_CXX_WARN_ADD. Since this macro expands to different
code after AC_LANG_PUSH([C++]) than after AC_LANG_PUSH([C]), it is wrong
to just AC_REQUIRE it. Needs to be a bit more intelligent.
Look at how _AC_LANG_ABBREV and _AC_LANG_PREFIX can be used. Maybe libtool.m4,
which also plays around with AC_LANG, gives you some hint about this.
I didn't fully understand this bit. I see that
_AC_LANG_ABBREV/_AC_LANG_PREFIX are used to inject the name of the language
into the names of variables. I see that gl_UNKNOWN_WARNINGS_ARE_ERRORS
changes depending on the language because gl_COMPILER_OPTION_IF changes.
(By the way, can we now assume autoconf 2.64 (of July 2009) or newer and
hence quote gl_Warn, as per the comment, there?)

Since gl_UNKNOWN_WARNINGS_ARE_ERRORS is therefore language-dependent, that
makes me think it needs to be called, not AC_REQUIREd, by
gl_{CXX_,}_WARN_ADD (because the language might change each time), but if
it were that simple, you'd've said so. So I'm not sure what else is needed


​I attach the latest state of play, which consists simply of updated
versions of manywarnings.m4 and warnings.m4, in place of the new files I
had before. (To test them I have simply placed them in a gnulib patch
directory which is applied by bootstrap; I love how simple it is!)
--
http://rrt.sc3d.org
Reuben Thomas
2017-03-07 12:20:54 UTC
Permalink
Post by Reuben Thomas
​I attach the latest state of play, which consists simply of updated
versions of manywarnings.m4 and warnings.m4, in place of the new files I
had before. (To test them I have simply placed them in a gnulib patch
directory which is applied by bootstrap; I love how simple it is!)
​Ping!

(By the way, if my emails are still being listed as spam because of
SPF/DKIM interacting badly with the listserv, does anyone have any
suggestion as to the most effective place to ask nicely for the listserv to
be suitably upgraded/configured?)
--
http://rrt.sc3d.org
Reuben Thomas
2017-08-05 17:19:38 UTC
Permalink
Post by Reuben Thomas
Post by Reuben Thomas
​I attach the latest state of play, which consists simply of updated
versions of manywarnings.m4 and warnings.m4, in place of the new files I
had before. (To test them I have simply placed them in a gnulib patch
directory which is applied by bootstrap; I love how simple it is!)
​Ping!
​Ping!! Attached, the latest version of my patches (in fact they've not
changed since last time, but there is an extra file I forgot to include
before), and now I attach patches to existing files as such rather than as
complete files.

For reference, these versions do not address this request from Bruno:

Please also fix the AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS]) invocation in
Post by Reuben Thomas
gl_WARN_ADD and gl_CXX_WARN_ADD. Since this macro expands to different code
after AC_LANG_PUSH([C++]) than after AC_LANG_PUSH([C]), it is wrong to
just AC_REQUIRE it. Needs to be a bit more intelligent.
Look at how _AC_LANG_ABBREV and _AC_LANG_PREFIX can be used. Maybe
libtool.m4, which also plays around with AC_LANG, gives you some hint
about this.
​I previously replied:​

I didn't fully understand this bit. I see that _AC_LANG_ABBREV/_AC_LANG_PREFIX
Post by Reuben Thomas
are used to inject the name of the language into the names of variables. I
see that gl_UNKNOWN_WARNINGS_ARE_ERRORS changes depending on the language
because gl_COMPILER_OPTION_IF changes. (By the way, can we now assume
autoconf 2.64 (of July 2009) or newer and hence quote gl_Warn, as per the
comment, there?)
Since gl_UNKNOWN_WARNINGS_ARE_ERRORS is therefore language-dependent, that
makes me think it needs to be called, not AC_REQUIREd, by
gl_{CXX_,}_WARN_ADD (because the language might change each time), but if
it were that simple, you'd've said so. So I'm not sure what else is needed

--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Paul Eggert
2017-08-05 18:48:23 UTC
Permalink
Thanks, as I try to avoid C++ I hope Bruno has the time to review that one.
Bruno Haible
2017-08-06 22:50:32 UTC
Permalink
Hi Reuben,
I've now addressed this issue. I hope you'll find the new code structure
more systematic.

Here's how I see the status / needed tweaks on your patches:
- warnings.m4: No change needed any more.
- manywarnings.m4: define gl_MANYWARN_ALL_GCC(C++) instead of gl_MANYWARN_ALL_GXX.
- g++-warning.spec: Looks OK to me. I trust that your C++ experience is
fresher than mine (I learned C++ in 1997).
Do you agree?

Bruno
Reuben Thomas
2017-08-07 11:56:14 UTC
Permalink
Post by Bruno Haible
Hi Reuben,
I've now addressed this issue. I hope you'll find the new code structure
more systematic.
​Thanks very much for this. The main feature of the code which I'd not
anticipated (nor even known it was possible) is the ability to AC_DEFUN a
macro with a particular argument, as in:​

​AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],​

so that it is possible to AC_REQUIRE such a macro.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Reuben Thomas
2017-08-07 15:14:19 UTC
Permalink
Post by Reuben Thomas
the ability to AC_DEFUN a
macro with a particular argument, as in:​
​AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],​
so that it is possible to AC_REQUIRE such a macro.
The '(C)' part is not an argument to the function. It's part of the
function name. By convention, such a function name is used to indicate the
implementation of an autoconf macro for a particular _AC_LANG value.
​So how does one supply an argument? Is it

gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)([variable])?​
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Eric Blake
2017-08-07 15:39:02 UTC
Permalink
Post by Reuben Thomas
Post by Reuben Thomas
the ability to AC_DEFUN a
macro with a particular argument, as in:​
​AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],​
so that it is possible to AC_REQUIRE such a macro.
The '(C)' part is not an argument to the function. It's part of the
function name. By convention, such a function name is used to indicate the
implementation of an autoconf macro for a particular _AC_LANG value.
​So how does one supply an argument? Is it
gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)([variable])?​
Such a function can only be called indirectly (and in fact, AC_REQUIRE
is probably the best such way to call it indirectly). Autoconf's
AC_LANG magic already knows how to indirectly call several macros
defined with different language-specific mechanisms, and it looks like
this patch is adding another similar use.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Reuben Thomas
2017-08-07 12:21:44 UTC
Permalink
Post by Bruno Haible
- g++-warning.spec: Looks OK to me. I trust that your C++ experience is
fresher than mine (I learned C++ in 1997).
​I simply went through the GCC manual and gcc-warning.spec and added in C++
warnings and removed those which were C only. I'm working with C++ in
Enchant at present, but I can't say I'm well up on modern C++ (or indeed
any other flavour).

I attach an updated patch against manywarnings.m4, and, for simplicity, the
same g++-warning.spec.

There's one issue left that I'm aware of: the recipe in the comments of the
C and C++ flavors of gl_MANYWARN_ALL_GCC for comparing the *.spec list of
warnings with one's own compiler no longer works, since it will grep all
the warnings for all languages defined in manywarnings.m4. I'm unsure how
best to fix this.

Currently in my configure.ac, I have:

AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])

dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP

which seems to work. However, it seems I should be able to call
gl_MANYWARN_ALL_GCC(C++) directly; but where then do I put the argument
giving the variable in which to put the warnings? I'm confused by the
apparent argument in the name of the macro!

I guess this explains why gl_MANYWARN_ALL_GCC({C,C++}) still contain
AC_LANG_PUSH/POP pairs, as they can in fact be called directly?
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Bruno Haible
2017-08-07 15:42:04 UTC
Permalink
Hi Reuben,
​I simply went through the GCC manual and gcc-warning.spec and added in C++
warnings and removed those which were C only. I'm working with C++ in
Enchant at present, but I can't say I'm well up on modern C++ (or indeed
any other flavour).
OK, then if we find that some warnings are counterproductive, we can disable
them afterwards, on a case-by-case basis.
There's one issue left that I'm aware of: the recipe in the comments of the
C and C++ flavors of gl_MANYWARN_ALL_GCC for comparing the *.spec list of
warnings with one's own compiler no longer works, since it will grep all
the warnings for all languages defined in manywarnings.m4.
Ah, good point. I fixed this by moving the new code to a separate file
manywarnings-c++.m4. This makes it also easier to 'diff' the two cases.


2017-08-06 Reuben Thomas <***@sc3d.org>

manywarnings: Add support for C++.
* build-aux/g++-warning.spec: New file.
* m4/manywarnings-c++.m4: New file.
* modules/manywarnings (Files): Add it.
AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])
dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP
which seems to work.
Yes, this is how the multi-language facilities are supposed to be used.
However, it seems I should be able to call
gl_MANYWARN_ALL_GCC(C++) directly
How about this?
m4_indir([gl_MANYWARN_ALL_GCC(C++)], [my_cxx_warning_options])
See [1]. Yuck, that's where the GNU Build System gets ugly.
I guess this explains why gl_MANYWARN_ALL_GCC({C,C++}) still contain
AC_LANG_PUSH/POP pairs, as they can in fact be called directly?
The main reason why the AC_LANG_PUSH/POP pairs are still there is that the
macros can be AC_REQUIREd. If you write

AC_DEFUN([MY_FOO], [
AC_LANG_PUSH([C++])
AC_REQUIRE([gl_MANYWARN_ALL_GCC(C++)])
...
])

the expansion of gl_MANYWARN_ALL_GCC(C++) will end up _before_ the
AC_LANG_PUSH([C++]).

Bruno

[1] https://www.gnu.org/software/m4/manual/m4-1.4.15/html_node/Indir.html
Reuben Thomas
2017-08-07 16:11:17 UTC
Permalink
Post by Bruno Haible
Post by Bruno Haible
AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])
dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP
which seems to work.
Yes, this is how the multi-language facilities are supposed to be used.
​OK, now that some of the code is in a new file, I get:

configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level

Line 90 is the call of gl_MANYWARN_ALL_GCC in the code extract above.​

The main reason why the AC_LANG_PUSH/POP pairs are still there is that the
Post by Bruno Haible
macros can be AC_REQUIREd.
​Ah, I see, thanks.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Reuben Thomas
2017-08-07 16:16:42 UTC
Permalink
Post by Reuben Thomas
Post by Bruno Haible
Post by Bruno Haible
AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])
dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP
which seems to work.
Yes, this is how the multi-language facilities are supposed to be used.
configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level
Line 90 is the call of gl_MANYWARN_ALL_GCC in the code extract above.​
​many​warnings-c++.m4 is not referenced in aclocal.m4, though it has been
symlinked into the project's m4 directory by bootstrap.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Reuben Thomas
2017-08-07 16:21:19 UTC
Permalink
Post by Reuben Thomas
Post by Reuben Thomas
Post by Bruno Haible
Post by Bruno Haible
AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])
dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP
which seems to work.
Yes, this is how the multi-language facilities are supposed to be used.
configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level
Line 90 is the call of gl_MANYWARN_ALL_GCC in the code extract above.​
​many​warnings-c++.m4 is not referenced in aclocal.m4, though it has been
symlinked into the project's m4 directory by bootstrap.
​
Is this because aclocal finds gl_MANYWARN_ALL_GCC defined in
manywarnings.m4, so doesn't bother looking in manywarnings-c++.m4?
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Reuben Thomas
2017-08-07 16:29:57 UTC
Permalink
Post by Reuben Thomas
Post by Reuben Thomas
Post by Reuben Thomas
Post by Bruno Haible
Post by Bruno Haible
AC_LANG_PUSH([C++])
gl_MANYWARN_ALL_GCC([cxx_warnings])
dnl Enable all G++ warnings not in this list.
gl_MANYWARN_COMPLEMENT([cxx_warnings], [$cxx_warnings], [$nw])
for w in $cxx_warnings; do
gl_WARN_ADD([$w])
done
AC_LANG_POP
which seems to work.
Yes, this is how the multi-language facilities are supposed to be used.
configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level
Line 90 is the call of gl_MANYWARN_ALL_GCC in the code extract above.​
​many​warnings-c++.m4 is not referenced in aclocal.m4, though it has been
symlinked into the project's m4 directory by bootstrap.
​
Is this because aclocal finds gl_MANYWARN_ALL_GCC defined in
manywarnings.m4, so doesn't bother looking in manywarnings-c++.m4
​.
​So as a workaround, I tried replacing the line

gl_MANYWARN_ALL_GCC([cxx_warnings])

by

m4_indir([gl_MANYWARN_ALL_GCC(C++)], [cxx_warnings])

​but now I get a straightforward error from aclocal:​

/usr/bin/m4:configure.ac:90: undefined macro `gl_MANYWARN_ALL_GCC(C++)'

​I guess because aclocal doesn't scan for macros called via m4_indir??​
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Bruno Haible
2017-08-07 17:12:48 UTC
Permalink
Post by Reuben Thomas
configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level
Ah, 'aclocal' does not grok that it needs to include manywarnings-c++.m4 in
aclocal.m4. Does it work with this change?


diff --git a/m4/manywarnings-c++.m4 b/m4/manywarnings-c++.m4
index cb1548a..c023f88 100644
--- a/m4/manywarnings-c++.m4
+++ b/m4/manywarnings-c++.m4
@@ -4,9 +4,9 @@ dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.

-# Specialization of gl_MANYWARN_ALL_GCC for _AC_LANG = C++.
-# This macro can be AC_REQUIREd.
-AC_DEFUN([gl_MANYWARN_ALL_GCC(C++)],
+# Implementation of the specialization of gl_MANYWARN_ALL_GCC
+# for _AC_LANG = C++.
+AC_DEFUN([gl_MANYWARN_ALL_GCC_CXX_IMPL],
[
AC_LANG_PUSH([C++])

diff --git a/m4/manywarnings.m4 b/m4/manywarnings.m4
index 3124b1e..a3d255a 100644
--- a/m4/manywarnings.m4
+++ b/m4/manywarnings.m4
@@ -38,7 +38,7 @@ AC_DEFUN([gl_MANYWARN_COMPLEMENT],
AC_DEFUN([gl_MANYWARN_ALL_GCC],
[_AC_LANG_DISPATCH([$0], _AC_LANG, $@)])

-# Specialization for _AC_LANG = C. This macro can be AC_REQUIREd.
+# Specialization for _AC_LANG = C.
AC_DEFUN([gl_MANYWARN_ALL_GCC(C)],
[
AC_LANG_PUSH([C])
@@ -314,3 +314,9 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC(C)],

AC_LANG_POP([C])
])
+
+# Specialization for _AC_LANG = C++.
+AC_DEFUN([gl_MANYWARN_ALL_GCC(C++)],
+[
+ gl_MANYWARN_ALL_GCC_CXX_IMPL([$1])
+])
Reuben Thomas
2017-08-07 19:25:51 UTC
Permalink
Post by Bruno Haible
Post by Reuben Thomas
configure.ac:90: error: gl_MANYWARN_ALL_GCC: unknown language: C++
m4/manywarnings.m4:38: gl_MANYWARN_ALL_GCC is expanded from...
configure.ac:90: the top level
Ah, 'aclocal' does not grok that it needs to include manywarnings-c++.m4 in
aclocal.m4. Does it work with this change?
​Thanks, that seems to fix it.​
Bruno Haible
2017-08-07 20:09:18 UTC
Permalink
​Thanks, that seems to fix it.​
Good! So, I've pushed it.

Bruno
Reuben Thomas
2017-08-07 20:11:48 UTC
Permalink
Post by Bruno Haible
Post by Reuben Thomas
​Thanks, that seems to fix it.​
Good! So, I've pushed it.
​Thanks very much, that means I'm down to only one gnulib diff in Enchant,
which adds extra project-specific instructions to INSTALL.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
Bruno Haible
2017-08-06 22:41:31 UTC
Permalink
Post by Bruno Haible
Please also fix the AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS]) invocation
in gl_WARN_ADD and gl_CXX_WARN_ADD. Since this macro expands to different
code after AC_LANG_PUSH([C++]) than after AC_LANG_PUSH([C]), it is wrong
to just AC_REQUIRE it. Needs to be a bit more intelligent.
Look at how _AC_LANG_ABBREV and _AC_LANG_PREFIX can be used. Maybe libtool.m4,
which also plays around with AC_LANG, gives you some hint about this.
To fix this, I prepared a test project (attached), and modified warnings.m4
and manywarnings.m4 until
$ ./autogen.sh
$ rm -f config.cache; ./configure -C
produced the config.status and config.cache that I expected.


2017-08-06 Bruno Haible <***@clisp.org>

warnings, manywarnings: Add support for multiple languages, not just C.
* warnings.m4 (gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL): Renamed from
gl_UNKNOWN_WARNINGS_ARE_ERRORS.
(gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)): New macro.
(gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)): New macro.
(gl_UNKNOWN_WARNINGS_ARE_ERRORS): Dispatch to
gl_UNKNOWN_WARNINGS_ARE_ERRORS(_AC_LANG).
(gl_WARN_ADD): Require the gl_UNKNOWN_WARNINGS_ARE_ERRORS specialization
of the current language. If C++ is the current language, modify
WARN_CXXFLAGS instead of WARN_CFLAGS.
* manywarnings.m4 (gl_MANYWARN_ALL_GCC(C)): New macro, extracted from
gl_MANYWARN_ALL_GCC.
(gl_MANYWARN_ALL_GCC): Dispatch to gl_MANYWARN_ALL_GCC(_AC_LANG).

diff --git a/m4/manywarnings.m4 b/m4/manywarnings.m4
index 6a8939b..3124b1e 100644
--- a/m4/manywarnings.m4
+++ b/m4/manywarnings.m4
@@ -1,4 +1,4 @@
-# manywarnings.m4 serial 10
+# manywarnings.m4 serial 11
dnl Copyright (C) 2008-2017 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -33,8 +33,16 @@ AC_DEFUN([gl_MANYWARN_COMPLEMENT],
# Add all documented GCC warning parameters to variable VARIABLE.
# Note that you need to test them using gl_WARN_ADD if you want to
# make sure your gcc understands it.
+#
+# The effects of this macro depend on the current language (_AC_LANG).
AC_DEFUN([gl_MANYWARN_ALL_GCC],
+[_AC_LANG_DISPATCH([$0], _AC_LANG, $@)])
+
+# Specialization for _AC_LANG = C. This macro can be AC_REQUIREd.
+AC_DEFUN([gl_MANYWARN_ALL_GCC(C)],
[
+ AC_LANG_PUSH([C])
+
dnl First, check for some issues that only occur when combining multiple
dnl gcc warning categories.
AC_REQUIRE([AC_PROG_CC])
@@ -303,4 +311,6 @@ AC_DEFUN([gl_MANYWARN_ALL_GCC],
fi

$1=$gl_manywarn_set
+
+ AC_LANG_POP([C])
])
diff --git a/m4/warnings.m4 b/m4/warnings.m4
index e697174..aa2735b 100644
--- a/m4/warnings.m4
+++ b/m4/warnings.m4
@@ -1,4 +1,4 @@
-# warnings.m4 serial 11
+# warnings.m4 serial 12
dnl Copyright (C) 2008-2017 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -20,10 +20,12 @@ m4_ifdef([AS_VAR_APPEND],
# -----------------------------------------------------------------
# Check if the compiler supports OPTION when compiling PROGRAM.
#
-# FIXME: gl_Warn must be used unquoted until we can assume Autoconf
-# 2.64 or newer.
+# The effects of this macro depend on the current language (_AC_LANG).
AC_DEFUN([gl_COMPILER_OPTION_IF],
-[AS_VAR_PUSHDEF([gl_Warn], [gl_cv_warn_[]_AC_LANG_ABBREV[]_$1])dnl
+[
+dnl FIXME: gl_Warn must be used unquoted until we can assume Autoconf
+dnl 2.64 or newer.
+AS_VAR_PUSHDEF([gl_Warn], [gl_cv_warn_[]_AC_LANG_ABBREV[]_$1])dnl
AS_VAR_PUSHDEF([gl_Flags], [_AC_LANG_PREFIX[]FLAGS])dnl
AS_LITERAL_IF([$1],
[m4_pushdef([gl_Positive], m4_bpatsubst([$1], [^-Wno-], [-W]))],
@@ -51,27 +53,50 @@ AS_VAR_POPDEF([gl_Warn])dnl
# ------------------------------
# Clang doesn't complain about unknown warning options unless one also
# specifies -Wunknown-warning-option -Werror. Detect this.
+#
+# The effects of this macro depend on the current language (_AC_LANG).
AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS],
+[_AC_LANG_DISPATCH([$0], _AC_LANG, $@)])
+
+# Specialization for _AC_LANG = C. This macro can be AC_REQUIREd.
+AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C)],
+[
+ AC_LANG_PUSH([C])
+ gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL
+ AC_LANG_POP([C])
+])
+
+# Specialization for _AC_LANG = C++. This macro can be AC_REQUIREd.
+AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS(C++)],
+[
+ AC_LANG_PUSH([C++])
+ gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL
+ AC_LANG_POP([C++])
+])
+
+AC_DEFUN([gl_UNKNOWN_WARNINGS_ARE_ERRORS_IMPL],
[gl_COMPILER_OPTION_IF([-Werror -Wunknown-warning-option],
[gl_unknown_warnings_are_errors='-Wunknown-warning-option -Werror'],
[gl_unknown_warnings_are_errors=])])

-# gl_WARN_ADD(OPTION, [VARIABLE = WARN_CFLAGS],
+# gl_WARN_ADD(OPTION, [VARIABLE = WARN_CFLAGS/WARN_CXXFLAGS],
# [PROGRAM = AC_LANG_PROGRAM()])
-# ---------------------------------------------
-# Adds parameter to WARN_CFLAGS if the compiler supports it when
-# compiling PROGRAM. For example, gl_WARN_ADD([-Wparentheses]).
+# -----------------------------------------------------------
+# Adds parameter to WARN_CFLAGS/WARN_CXXFLAGS if the compiler supports it
+# when compiling PROGRAM. For example, gl_WARN_ADD([-Wparentheses]).
#
# If VARIABLE is a variable name, AC_SUBST it.
+#
+# The effects of this macro depend on the current language (_AC_LANG).
AC_DEFUN([gl_WARN_ADD],
-[AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS])
+[AC_REQUIRE([gl_UNKNOWN_WARNINGS_ARE_ERRORS(]_AC_LANG[)])
gl_COMPILER_OPTION_IF([$1],
- [gl_AS_VAR_APPEND(m4_if([$2], [], [[WARN_CFLAGS]], [[$2]]), [" $1"])],
+ [gl_AS_VAR_APPEND(m4_if([$2], [], [[WARN_]_AC_LANG_PREFIX[FLAGS]], [[$2]]), [" $1"])],
[],
[$3])
m4_ifval([$2],
[AS_LITERAL_IF([$2], [AC_SUBST([$2])])],
- [AC_SUBST([WARN_CFLAGS])])dnl
+ [AC_SUBST([WARN_]_AC_LANG_PREFIX[FLAGS])])dnl
])

# Local Variables:
Bruno Haible
2017-02-21 15:05:21 UTC
Permalink
Hi Reuben,
​For example, would it be sensible to have a single spec file, with each
warning language-list comment
i.e. the first and third columns as at present, and the second giving the
languages for which the flag is used?
In my opinion

1) How to specify the set of options to avoid is orthogonal to the C vs C++
consideration.

2) I find the usage approach from
https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html
to be just as easy to use as a .spec file, and furthermore it is more
flexible:
- It allows to use different sets of warnings for clang than for gcc
(remember that clang disguises as gcc). You need a line such as
CC_BRAND=`LC_ALL=C $CC --version | sed -e '2,$d' -e 's/ .*//'` # either gcc or clang
to distinguish them.
- It allows multiline descriptions why a warning is avoided.

Bruno
Reuben Thomas
2017-02-21 15:11:08 UTC
Permalink
Post by Bruno Haible
Hi Reuben,
Post by Reuben Thomas
​For example, would it be sensible to have a single spec file, with each
warning language-list comment
i.e. the first and third columns as at present, and the second giving the
languages for which the flag is used?
In my opinion
1) How to specify the set of options to avoid is orthogonal to the C vs C++
consideration.
Sorry, I think I confused things, I should have said "the second giving the
list of languages for which the flag is [explicitly] disabled".

2) I find the usage approach from
Post by Bruno Haible
https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html
to be just as easy to use as a .spec file, and furthermore it is more
- It allows to use different sets of warnings for clang than for gcc
(remember that clang disguises as gcc). You need a line such as
CC_BRAND=`LC_ALL=C $CC --version | sed -e '2,$d' -e 's/ .*//'` # either gcc or clang
to distinguish them.
- It allows multiline descriptions why a warning is avoided.
​I agree, I use this approach. Maybe I misunderstood what the specfile is
for: I thought it was a way to generate and check the list of ​warning
flags to go in manywarnings.m4, not something one would directly use in a
project.
--
http://rrt.sc3d.org
Loading...