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
Description: Binary data
