[Top][All Lists]

[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: Tue, 21 Feb 2017 15:58:14 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-62-generic; KDE/5.18.0; x86_64; ; )

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.

> 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

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.


reply via email to

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