bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: manywarnings for C++


From: Bruno Haible
Subject: Re: manywarnings for C++
Date: Mon, 07 Aug 2017 17:42:04 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-83-generic; KDE/5.18.0; x86_64; ; )

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  <address@hidden>

        manywarnings: Add support for C++.
        * build-aux/g++-warning.spec: New file.
        * m4/manywarnings-c++.m4: New file.
        * modules/manywarnings (Files): Add it.


> 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]