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

[Akim Demaille]

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