[Top][All Lists]

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

Re: warnings.m4: check the compiler, not the preprocessor.

From: Akim Demaille
Subject: Re: warnings.m4: check the compiler, not the preprocessor.
Date: Fri, 4 May 2012 08:28:57 +0200

Hi Bruno,

Can this patch be installed?  I'm depending on it in Bison.

Le 16 avr. 2012 à 11:28, Akim Demaille a écrit :

> The attached patch enhances warnings.m4 in several important
> ways:
> - gl_COMPILER_OPTION_IF allows to define more fined
> grained tests on the behavior of the compiler.  Forcing
> the result to be an assignment to a variable (which is
> AC_SUBST) does not seem to offer the orthogonal design
> one would expect.  This would be useful elsewhere, for
> instance in manywarnings, as I have already reported it
> (see below, and
> http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00198.html)
> - separating the diagnostic part from the action part
> provides a cleaner way to implement test cases.
> - separating the diagnostic part from the action part
> helps extending both in a cleaner way:
> - it allowed me to cleanly integrate the missing
>  AC_SUBST for WARN_CFLAGS instead of leaving this
>  to modules/warnings
> - it will make it easier to check for the answers
>  of the compiler on stderr
> - the added parameter to gl_WARN_ADD allows to fine
> tune whether a given warning is wanted or not, as
> was explained in the message I am responding to.
> If there are flaws in this patch to address, I'd be happy to!
>       Akim
> Le 9 avr. 2012 à 09:52, Akim Demaille a écrit :
>> Le 30 mars 2012 à 11:55, Akim Demaille a écrit :
>>> Le 30 mars 2012 à 11:18, Bruno Haible a écrit :
>>>>> 0002-warnings.m4-exhibit-an-if-else-interface.patch
>>>> What is the point of this patch? Those who want to assign to a different
>>>> variable than WARN_CFLAGS can already do so through gl_WARN_ADD. Your
>>>> patch looks like unneeded complexity to me.
>>> On the other hand it provides a more classical interface,
>>> if one wants to issue a warning or a error message if some
>>> option is not supported.  Besides, it prepares for more
>>> changes if we want to make more complex check on the way
>>> the compiler supports the option (as I suggested earlier).
>>> It allows to clear separate the test part from the action
>>> part.  More lines, but I would argue that it is not
>>> added complexity, but are less complexity.
>>> It would allow to remove some useless duplication in gnulib.
>>> Say manywarnings:
>>> dnl First, check -W -Werror -Wno-missing-field-initializers is supported
>>> dnl with the current $CC $CFLAGS $CPPFLAGS.
>>> AC_MSG_CHECKING([whether -Wno-missing-field-initializers is supported])
>>> AC_CACHE_VAL([gl_cv_cc_nomfi_supported], [
>>> gl_save_CFLAGS="$CFLAGS"
>>> CFLAGS="$CFLAGS -W -Werror -Wno-missing-field-initializers"
>>>   [AC_LANG_PROGRAM([[]], [[]])],
>>>   [gl_cv_cc_nomfi_supported=yes],
>>>   [gl_cv_cc_nomfi_supported=no])
>>> CFLAGS="$gl_save_CFLAGS"])
>>> AC_MSG_RESULT([$gl_cv_cc_nomfi_supported])
>>> Actually, it would be even helpful to be able to provide
>>> the code to compile, instead of just AC_LANG_PROGRAM.
>> Well, I hit a case where I would like to specify the
>> program to compile: G++ 4.7 supports a warning about
>> 0 being used as a pointer type, even when it does not
>> support nullptr because its C++11 mode is not activated.
>> In other words, I'd like this warning provided that
>> nullptr is supported.  This is easy to do with the
>> following proposed patch.
>> <0001-warnings.m4-provide-a-means-to-specify-the-program-t.patch>

Attachment: 0001-warnings.m4-provide-a-means-to-specify-the-program-t.patch
Description: Binary data

reply via email to

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