Re: [PATCH 04/10] gtk.inc: add feature based on directfb

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

On Fri, 2011-12-09 at 07:51 +0100, Koen Kooi wrote:
> Op 8 dec. 2011, om 22:59 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-12-08 at 17:12 +0000, Phil Blundell wrote:
> >> On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote:
> >>> The question is whether it makes sense to have directfb and X based gtk
> >>> in the same builds and package feeds or not. I can see that it might be
> >>> desired and that it likely is possible.
> >> 
> >> This is true, though there's nothing to stop a distro that particularly
> >> wants this from inventing their own stub recipes which just set
> >> PACKAGECONFIG appropriately and then require the generic version.  So
> >> it's really just a question of what we want to be the default in
> >> oe-core.
> >> 
> >> Also note that, although you can parallel install multiple versions of
> >> the gtk+ runtime on the target system, if you want the build system to
> >> be deterministic then (in the absence of per-recipe sysroot
> >> construction) you need some way to decide which one gets to provide the
> >> gtk+-2.0.pc that other recipes will build against.  (The different
> >> targets have different library sonames so you can't just swap them out
> >> at run time: a given binary will remain coupled to the particular Gtk
> >> variant that it was compiled against.)  And if the two variants could
> >> conceivably be different versions of GTK then you also need a way to
> >> deconflict ${includedir}/gtk-2.0.  
> >> 
> >> So it isn't quite as simple as just having the two recipes, there is a
> >> bit of extra policy involved as well.  And of course there would be all
> >> the normal overhead in terms of parse time, memory footprint and
> >> maintenance burden associated with having more recipes.  
> > 
> > This is the key detail I was missing. I thought they just might have
> > been a drop in replacement.
> > 
> > That isn't the case so this makes the choice easier, I think separate
> > recipes don't make sense based on this.
> > 
> >> So, in light of all the above plus the fact that everything is different
> >> with Gtk+3 anyway, my preference for supporting directfb on gtk+2 in
> >> oe-core would be to use PACKAGECONFIG and not have separate recipe
> >> files.
> > 
> > Agreed, given the above.
> 
> So to be safe and give other directfb implementations a change, can
> this PACKAGECONFIG option be named 'gtk-directfb' in DISTRO_FEATURES?

I think that is reasonable.

Cheers,

Richard