GNOME Bugzilla – Bug 694757
build: Use separate GLIB_WARN_CFLAGS that can be overridden externally
Last modified: 2013-02-27 13:51:28 UTC
Some (broken) toolchains for example trip up -Werror=missing-prototypes in system headers. This patch allows people to skip the formerly hardcoded "baseline" warnings by doing: $ GLIB_WARN_CFLAGS="-Wall" ./configure ...
Created attachment 237460 [details] [review] 0001-build-Use-separate-GLIB_WARN_CFLAGS-that-can-be-over.patch
The other option is to add --disable-compile-warnings. Thinking about this a bit more, maybe that is better.
Created attachment 237472 [details] [review] 0001-build-Add-disable-compile-warnings.patch
Comment on attachment 237472 [details] [review] 0001-build-Add-disable-compile-warnings.patch >+AC_ARG_ENABLE(compile-warnings, "more-warnings" seems to be the most common convention: danw@laptop:gnome> grep -h 'AC_ARG_ENABLE.*warning' */configure.ac | sort | uniq -c 1 AC_ARG_ENABLE(compile_warnings, 2 AC_ARG_ENABLE(compile-warnings, 1 AC_ARG_ENABLE(development, [ --enable-development Enable any development warnings/incomplete code], [development=$enableval], [development="no"]) 2 AC_ARG_ENABLE([fatal-warnings], 1 AC_ARG_ENABLE([gcc-warnings], 12 AC_ARG_ENABLE(more-warnings, 1 AC_ARG_ENABLE(warnings, otherwise it looks good
although --enable/disable-compile-warnings makes more sense really, so if you want to declare the other modules to be wrong, I'd buy that. :)
(In reply to comment #5) > although --enable/disable-compile-warnings makes more sense really, so if you > want to declare the other modules to be wrong, I'd buy that. :) I followed gnome-common, and I think it makes sense to unify more modules around that.