Created attachment 196042 [details] [review]
Add GNOME_STRICT macro

Add a new GNOME_STRICT macro.  When this appears in configure.ac, a new
argument --enable-strict is added and a STRICT_FLAGS substitution is
defined.

By default, STRICT_FLAGS is empty.  Using --enable-strict causes
STRICT_FLAGS to be set to contain -Werror as well as
-DG_DISABLE_DEPRECATED and equivalent flags for most commonly-used
libraries in the GNOME platform.

The idea is that maintainers can use --enable-strict to check their
modules for correctness, but casual builders of the module (from
tarball, jhbuild or otherwise) will not be harmed.

At the same time, deprecate GNOME_MAINTAINER_MODE_DEFINES and define it
in terms of the new GNOME_STRICT.

I already discussed this in the release team mailing list [1] after ask in the autoconf mailing list [2]. This is the propossed code:

dnl ---------------------------------------------------------------------------
dnl - Use strict options (default enabled for devs, disabled in releases)
dnl ---------------------------------------------------------------------------
dnl if .git directory is present, considering we are working in the repository

test -d "$(srcdir)/.git"; then
        default_strict=yes
else
        default_strict=no
fi

AC_ARG_ENABLE([strict],
              [AS_HELP_STRING([--enable-strict],
                              [Enable strict compilation options])],
              [enable_strict=$enableval],
              [enable_strict=$default_strict])

if test x$enable_strict != xno; then
    CPPFLAGS="$CPPFLAGS -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED"
fi



There is already a discussion to add a macro like this in bug #614360 and a suggestion to include it in Glib in bug #635328

[1] https://mail.gnome.org/archives/release-team/2011-June/msg00030.html
[2] http://lists.gnu.org/archive/html/autoconf/2011-06/msg00026.html

I don't like the check for .git because it will hit casual users of jhbuild.

Combining -Werror with the deprecated flags will be a nightmare, we don't want that, really :-) (Else, it's just not possible to port step by step an app using deprecated API).

Also, --enable-strict is a nice name, but it's probably way too generic without a namespace. So --enable-gnome-strict, maybe?

And what about --gnome-disable-deprecated, if you remove -Werror?

Also, I'd introduce this macro in Glib instead gnome-common, as Its useful not only for GNOME projects.

I think we would not accept this macro in GLib for a few reasons.

First, it's a bit of a mess to have a list of random GNOME packages in GLib.  Some pkg-config based solution would really be better here.

Second, we have an intention to move away from macro-based deprecations in GLib toward GCC-attribute-based deprecations, so this is all a bit out of tune with that anyway.

Marking as OBSOLETE as we have now deprecation warnings when compiling in Glib/GTK+/GObject libraries