bug-gnulib
[Top][All Lists]
Advanced

[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: Mon, 9 Apr 2012 09:52:38 +0200

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.

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]