Hi! I have submitted this patch several times in this thread (starting at http://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00049.html), and for some reason it remains unnoticed, and uncommented. Please let me know what is wrong in my approach.
I would like to wrap a Bison 2.5.1 soon, and I expect to use this patch to decide whether I enable -Wzero-as-null-pointer-constant (as G++ can happily reject 0 as a pointer without supporting nullptr, not considered as a bug by G++ people). The attached patch enhances warnings.m4 in several ways: - gl_COMPILER_OPTION_IF allows to define more fine grain tests on the behavior of the compiler. Forcing the result to be an assignment to a variable (which is AC_SUBST'ed) 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 (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 (as currently, we merely check whether the compiler rejects the candidate option with an error status; this results in uselessly long compilation command lines, and spurious warnings in some situations). - the added parameter to gl_WARN_ADD allows to fine tune whether a given warning is wanted or not (e.g., 0 vs. nullptr as above). If there are flaws to address in this patch, I'd be happy to. Akim
0001-warnings.m4-provide-a-means-to-specify-the-program-t.patch
Description: Binary data
