[poky] non-upstreamed patches

[Richard Purdie]

On Mon, 2011-11-14 at 19:05 -0500, Colin Walters wrote:
> 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.

I certainly remember those days and can appreciate why this kind of
thing exists (we have the same problem with the OE codebase in many
ways).

> 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.

FWIW, we already do this for intltool:

	if grep "^[[:space:]]*[AI][CT]_PROG_INTLTOOL" $CONFIGURE_AC >/dev/null; then
	  bbnote Executing intltoolize --copy --force --automake
	  intltoolize --copy --force --automake
	fi

so we might even use gtkdocize, but have modified files for it to place
into the system. Strange as it might sound I'd actually like to be able
to generate the docs if possible. It is completely the same as the
introspection case where we need to be able to run target binaries or
could a set of -native binaries get us through of most of the difficult
bits?

The reason I mention docs is that we generate -doc packages. I have an
idea of being able to generate the technical reference that would go
alongside a given image. Obviously the gtkdoc pieces would be an
important part of that. Creating the -doc packages is part of that, the
remaining tricky part would then be indexing them in a sane way that was
useful and accessible.

Cheers,

Richard