Re: non-upstreamed patches

[Colin Walters <walters@verbum.org>]

On Mon, 2011-11-14 at 22:44 +0000, Richard Purdie wrote:

> Well, I went and looked at the gnome-common autogen stuff. Its not a
> cross specific problem in this case but it does seem to
> reinvent/reimplement pieces of what autoconf/pkgconfig is supposed to
> do. Compare/check autoconf version? automake version? pkg-config
> dependencies present? Why? The whole point of autoconf was to avoid
> having these scripts :(

They serve a few purposes; one is simply helping people who check out a
given module from git know they have compatible versions of the
autotools.  This used to be a major problem, nowadays it's been a long
time since any kind serious of autotools incompatibilities.

The still-relevant issue though is that autoreconf isn't extensible - in
GNOME for better or worse we have two things that follow the auto* style
(gtk-doc and intltool mainly) where they copy data into your system if
building from git, and get shipped in tarballs so you don't need them at
build time when building from tarballs.

But we have no way to tell autoreconf to run these tools currently.
Maybe the right thing is to extend autoreconf but even if we did that,
we'd have to wait some amount of time before assuming everyone had the
modified autoreconf.

> Our current hack is really the former approach - add dummy copies in.
> Its just a little incomplete and we should enhance it deal with that so
> we can run gtkdocize.

Hmmm...so we'd be patching autotools.bbclass to grep for e.g.
GTK_DOC_CHECK in configure.ac and if detected, copy in a dummy
gtk-doc.make and gtk-doc.m4?

(And the same for intltool?)

I wouldn't object too much to that I guess, but I'd still prefer the
solution where we opt-in to running autogen.sh for GNOME modules which
use gtk-doc and/or intltool.