Long live gnome-common? Macro deprecation

We’ve worked out the details, and have new recommendations for porting to autoconf-archive, including justifications and a migration guide. The information below is outdated.

gnome-common is shrinking, as we’ve decided to push as much of it as possible upstream. We have too many layers in our build systems, and adding an arbitrary dependency on gnome-common to pull in some macros once at configure time is not helpful — there are many cases where someone new has tried to build a module and failed with some weird autotools error about an undefined macro, purely because they didn’t have gnome-common installed.

So, for starters:

What does this mean for you, a module maintainer? Nothing, if you don’t want it to. gnome-common now contains copies of the autoconf-archive macros, and has compatibility wrappers for them.

In the long term, you should consider porting your build system to use the new, upstreamed macros. That means, for each macro:

  1. Downloading the macro to the m4/ directory in your project and adding it to git.
  2. Adding the macro to EXTRA_DIST in Makefile.am.
  3. Ensuring you have ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS} in your top-level Makefile.am.
  4. Updating the macro invocation in configure.ac; just copy out the shim from gnome-common.m4 and tidy everything up.

Here’s an example change for GNOME_CODE_COVERAGE ? AX_CODE_COVERAGE in libgdata.

It seems from the comments that there’s more discussion to be had about the best way to implement this. So hold off on these changes for the moment!

This is the beginning of a (probably) long road to deprecating a lot of gnome-common. Macros like GNOME_COMPILE_WARNINGS and GNOME_COMMON_INIT are next in the firing line — they do nothing GNOME-specific, and should be part of a wider set of reusable free software build macros, like the autoconf-archive. gnome-common’s support for legacy documentation systems (DocBook, anyone?) is also getting deprecated next cycle.

Comments? Get in touch with me or David King (amigadave). This work is the (long overdue) result of a bit of discussion we had at the Berlin DX hackfest in May.

9 thoughts on “Long live gnome-common? Macro deprecation

  1. swilmet

    > Downloading the macro to the m4/ directory in your project and adding it to git.

    Why is it needed? It is not convenient because the copy can get outdated after several years. If autoconf-archive is installed, it will take the latest installed version, no? Is it possible in autogen.sh to check if autoconf-archive is installed?

    1. Philip Withnall Post author

      The copy won’t get outdated over the years, though — if it works when you first add it to git, it will continue to work forever, unless you change your build system or upgrade autotools (but they have a very long-term deprecation policy). Think of it a bit like git.mk, which everyone seems happy with.

      While it’s possible to install autoconf-archive system-wide, I don’t think that’s the right approach.

      1. Julian Andres Klode

        Debian nowadays runs autoreconf on build time for most of the package; so yes, it can break. Not running autoreconf is not a solution either. A system-wide installation is the best idea.

  2. Javier Jardón

    This are great news!

    Im all to use upstream tools (or improve them) instead create our own solution.

    Things I've been working on and can be addded to your list:
    - gnome-autogen uses autoreconf internally instead a custom script
    - gettext recently added support for glade, gsettings, .desktop files ... so INTLTOOL is not needed anymore
    - A patch has been sen upstream to check for gtk-doc in autoreconf

    Maybe we can make a GnomeGoal to try to port as many modules as we can?

    1. Philip Withnall Post author

      Great! I’m not sure we’re at the state where a GnomeGoal would be appropriate to push for yet. I think it would be better to get a large number of improvements ready, and have maintainers apply them to their modules in a single go, rather than incessantly bombarding them with build system improvements. Build systems are, after all, not real work.

      Getting rid of intltool will be fantastic, thanks for working on (all of) this! 😀

      I plan to eliminate gnome-autogen.sh, and have some local changes to start eliminating things from it. If anybody’s interested, this is the sort of thing you can get away with: https://git.gnome.org/browse/libgdata/commit/autogen.sh?id=17364db93e6fc8095df9eea4bf127d8f66036fa1

  3. Philip Chimento

    I recently found out that ACLOCAL_AMFLAGS = -I m4 is deprecated -- replaced by AC_CONFIG_MACRO_DIR([m4]) in Automake 1.13 and later. It'll be removed in Automake 2.0.

    1. Philip Withnall Post author

      That’s interesting. As I understand it, both are currently needed as some (unspecified) tools look for the include dir in ACLOCAL_AMFLAGS, and some use AC_CONFIG_MACRO_DIR. Do you have a reference, or know when we can safely switch to AC_CONFIG_MACRO_DIR?

      1. Philip Chimento

        I got my info from old <a href="http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html&quot;?Automake release notes - I happened to be reading through them just the other day. The salient parts are:

        Macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS can now be used to declare the local m4 include directories. Accordingly, the special make variable ACLOCAL_AMFLAGS will become deprecated in future releases, and you should start moving away from it ASAP.


        Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS are now traced by aclocal, and can be used to declare the local m4 include directories. Formerly, one had to specify it with an explicit '-I' option to the 'aclocal' invocation.

        I don't know the rationale behind this and I don't know which tools would have cared about it other than aclocal itself. But if there were any, they would have had to have grepped through configure.ac, like gnome-autogen, and I always found that a bit of an abuse.

  4. Owen Taylor

    I originally wans't a gnome-common fan (preferred to roll-my-own auto*), but really warmed up to the idea over the years. When we moved away from copies of macros in m4/ to gnome-common, a lout of tedious maintenance work where a fix has to be chased across all the different modules went away.

    If macros actually move upstream to be distributed with autoconf/automake, that's an improvement, but it's not obvious to me that having copies of macros all over the GNOME source trees that have to be updated for fixes is better, just because the original source of the macro is "blessed" by it being in autoconf-archive. Is there any way we can make gnome-autogen.sh pull macros from the autoconf-archive git to avoid this?

    Essentially, I don't like having things checked into source control in multiple places.

    >> The copy won’t get outdated over the years, though — if it works when you first add it to git, it will continue to work forever, unless you change your build system or upgrade autotools

    It's not like module maintainers have control over the exact version of autotools that is being used with their project - the old school idea that the maintainer just ran 'make dist' on their system and that baked things into a tarball that everybody else uses doesn't really correspond to how we work these days.

Comments are closed.