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