m4-common

[Ryan Lortie <desrt desrt ca>]

karaj,

Philip and David have been undertaking an effort to boot gnome-common
out of our world by upstreaming (to automake-archive) some
(greatly-improved versions) of the macros.

The idea here is that other projects should be able to depend on those
macros without depending on gnome-common, and if our conventions are so
great, then why not allow others to follow them as well?

The upshot is that, if people start following these recommendations,
many GNOME modules will start to depend on macros from autoconf-archive.

There are generally two approaches to this, both of which suck:

 - copy/paste the dozen or so required macros into your version control

 - rely on autoconf-archive as a build dependency


I consider the copy/paste approach to be out of the question, a priori. 
Having 100 GNOME modules each with copies of 15 macros from a module
that's not even hosted in git.gnome.org is some kind of a disaster.  For
individual projects that want to reduce their external dependencies this
may be a viable solution, but I cannot suggest that we recommend this
for GNOME projects.

Relying on autoconf-archive comes with its own problems.  The versions
of autoconf-archive available in mainstream distributions are fairly
dated (and certainly don't contain the newest macros added by Philip and
Dave).  If we want to keep building on latest-Debian (jessie) then that
means that we would have to delay adoption of this new stuff by probably
as much as two years.

Building autoconf-archive as part of jhbuild also comes with its
problems: autoconf-archive is large (~550 macros, 3MB).  I don't want to
have to install all of that unnecessary stuff into jhbuild's install
prefix (think: binary package and VM downloads).  There is also the
problem that the upstream autoconf-archive package is difficult to build
under our assumptions of what a reasonable build environment looks like
(no standard build scripts, dependency on extra things like gnulib,
etc).

Finally, autoconf-archive also presents a problem for a release team who
needs to create a self-contained set of tarballs.  We do not have
release control over autoconf-archive, and having git versions of it in
jhbuild would expose us to the usual risk: our packages growing
dependencies on unreleased features that we are incapable of releasing
for ourselves.

As a compromise solution, I've created a module called m4-common:

  https://github.com/desrt/m4-common

The idea of this module is that it will include autoconf-archive as a
git submodule and it will install only the macros that we require from
it.  It is also 'make dist'able and will give us a tarball containing
only the modules that we are interested in.

I consider the submodule approach to be an implementation detail.  I'd
be open to changing it to directly containing the macros that we are
interested in and syncing up on an as-needed basis.  At least this would
reduce us to one location to keep up to date.

This solution is not without its own set of potential problems.  From a
distribution standpoint, there are now two packages (m4-common and
autoconf-archive) that install some of the same files into
/usr/share/aclocal.  Sometimes those files may have different content. 
Figuring out how to deal with this may be non-trivial.

The plan going forward would be to add m4-common to jhbuild as a
dependency of the modules that want to start using the new macros.  If a
macro from autoconf-archive becomes popular enough that several GNOME
modules are using it, we could add it to m4-common.

Thanks in advance for your opinions.

Cheers