[poky] non-upstreamed patches

[Richard Purdie]

On Mon, 2011-11-14 at 14:06 -0500, Colin Walters wrote:
> On Sun, 2011-11-13 at 09:47 +0000, Richard Purdie wrote:
> 
> > Totally agreed. We do have site cache files an a much better way of
> > handling that issue would be to add the value to the site cache. In an
> > ideal world I've have caught that patch and asked it to be a site entry,
> > it looks like its slipped through. I'll certainly take a site file entry
> > and change to drop the patch.
> 
> Ok, as I move forward I'll look at draining the patches here.  It'd be
> nice if we could try harder to avoid adding new ones though - that was
> my main goal with the mail.

Believe me, we're trying *very* hard to get the number of patches down!

> > > Another thing that seems to be proliferating is gtk-doc workarounds.  If
> > > it isn't working for you guys to --disable-gtk-doc, just tell me why and
> > > I'll fix it.
> > > 
> > This is a mess of our own making :/. You'd probably get a bit of a shock
> > if you look at our gtk-doc recipe. Since we reautoconf files, we need
> > the gtk-doc .m4 file. We just provide a static copy of it. To handle the
> > makefile, we just touch that.
> 
> Ah, I see.  Have you seen people.gnome.org/~walters/docs/build-api.txt ?
> 
> One of the reasons I wrote it is because in GNOME we need ./autogen.sh
> scripts because there's no easy way to teach the autotools about
> external dependencies.
> 
> What would you think about a patch to autotools.bbclass to just check
> for autogen.sh and run it (instead of the big mess of autoreconf/etc.
> hacks) if it exists?

The number of people who write cross safe autogen.sh scripts which do
everything we need is unfortunately low. I do appreciate the gnome
community may do better than others and things are improving over time.
I'd not yet at a point where I'd trust even 10% of the autogen.sh
scripts out there though.

I'm prepared to stick my neck out and state that the reautoconf we do
doesn't cause that much of a problem at this point and that class works
pretty well. The process for reautoconf'ing a package is pretty standard
when you get down to it. We did used to have a lot more hacky recipe
specific do_configure functions and we've managed to just have
the .bbclass code in most cases now too which is an achievement in
itself.

Cheers,

Richard