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
