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.
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.
p.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
