[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.
Thanks!
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_COMPILE_IFELSE(
>>> [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>
>>
0001-warnings.m4-provide-a-means-to-specify-the-program-t.patch
Description: Binary data
- Re: warnings.m4: check the compiler, not the preprocessor.,
Akim Demaille <=