Re: [PATCH 06/13] gtk+: import native support from meta-oe

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2012-03-22 at 07:51 +0100, Martin Jansa wrote:
> On Thu, Mar 22, 2012 at 12:02:44AM +0000, Richard Purdie wrote:
> > On Thu, 2012-03-22 at 00:50 +0100, Martin Jansa wrote:
> > > On Wed, Mar 21, 2012 at 11:11:16PM +0000, Richard Purdie wrote:
> > > > On Wed, 2012-03-21 at 22:36 +0100, Martin Jansa wrote:
> > > > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > > > ---
> > > > >  meta/recipes-gnome/gtk+/gtk+.inc |    4 ++++
> > > > >  1 files changed, 4 insertions(+), 0 deletions(-)
> > > > 
> > > > I really don't like the message having a gtk+-native around sends out.
> > > > Why do we need this?
> > > 
> > > See cover letter if you haven't already.
> > 
> > Sorry, I'd looked at it but I'd missed the key bit. I think I thought
> > the URL was a pull URL and my eyes skimmed it.
> 
> No problem,
> 
> > To be honest I don't think the update-icon-cache is good enough reason
> > to build a full gtk+-native. If we let these pieces in the dependencies
> > have a tendency to grow and people have no incentive to try and fix
> > these issues.
> 
> Well agreed, but most of those natives are needed for librsvg-native
> which in turn is used in navit build to generate icons (which I can
> hardly replace with something thiner then librsvg and using e.g.
> autodetected ksvgtopng from host is even worse for reproducible builds).

librsvg-native I don't mind as much, I'm ok with taking those patches.

> So for minimal gtk+-native I only need libx11-native and
> libxrander-native, but the problem is that PACKAGECONFIG without that
> fix ignores all -native depends and with fix it correctly adds -native
> to all non-native deps added by PACKAGECONFIG
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019348.html

Right, I'm aware of that issue and sorry for not responding yet.
Basically, I wanted to do some proper patch review and write a
reasonable response to it and I've been lacking the time to do so.

Firstly, I agree we need to fix it there is no question of that. The
patch moving everything to base.bbclass concerns me though, not least as
it undoes a lot of the work I've been trying to do with regard to
abstracting the bbclassextend code into lib/oe/*.py. I therefore think
an alternative approach is going to be needed but I've not managed to
come up with that yet :(.

> > I'd like to better understand why there is no other way to avoid this.
> 
> I can look into gtk+3 build what else we need to provide to be able to
> build without --enable-gtk2-dependency or how to disable
> update-icon-cache during build so that people with gtk+ installed on
> host and without get the same result package, but I'm not really
> interested in gtk+3 so I was just fixing another build failure :/ so it 
> can take some time...

This is one case I think we need to do the right thing and not take
short cuts. I don't mind the extends for librsvg-native but I don't want
to take gtk+-native or pango-native and any of the the dependencies only
they need.

I also agree we need to fix PACKAGECONFIG but I don't like the direction
the patch takes and haven't had time to come up with an alternative. I
wish I had more time and was able to give a better reply.

Cheers,

Richard