GNOME_COMPILE_WARNINGS is deprecated, but I think we need some way of hooking the AX_COMPILER_FLAGS --enable-compile-warnings flag to g-ir-scanner as well as the C compiler.

I’m putting this bug here for lack of a better place to put it. It can be moved later if needed.

I’m thinking we need an AC_SUBST([WARN_SCANNERFLAGS]), which sets
 • --warn-all unless --enable-compile-warnings=no; and
 • --warn-error if --enable-compile-warnings=error.

This could be done as a:
 1. modification to AX_COMPILER_FLAGS upstream; or a
 2. modification to GOBJECT_INTROSPECTION_CHECK in GLib;
 3. extension to GNOME_COMPILE_WARNINGS (even though it’s deprecated in bug #729407).

I’m not really sure which is the best approach.

#1 would complicate the argument list of AX_COMPILER_FLAGS further. In that case it might be better to split it up into something like:
    AX_COMPILER_FLAGS(TOOL-NAME, [VARIABLE], [IS-RELEASE], [EXTRA-BASE-FLAGS], …, [EXTRA-ERROR-FLAGS])
and have the user call it several times:
    AX_COMPILER_FLAGS([cc],[WARN_CFLAGS])
    AX_COMPILER_FLAGS([ld],[WARN_LDFLAGS])
    AX_COMPILER_FLAGS([g-ir-scanner],[WARN_SCANNERFLAGS])

#2 would be less invasive, but would mean GOBJECT_INTROSPECTION_CHECK has an implicit optional dependency on AX_COMPILER_FLAGS, and the warning flag stuff is no longer contained in AX_COMPILER_FLAGS. It could check the value of $ax_enable_compile_warnings to set its default flags.

#3 would mean un-deprecating GNOME_COMPILE_WARNINGS, which is a bit silly.

I guess I’m in favour of option #2, unless people think that option #1 is the better long-term solution, especially if AX_COMPILER_FLAGS is to gain support for more tools?