Hi Phil, On 15/05/13 21:49, Phil Blundell wrote: > On Wed, 2013-05-15 at 16:28 -0300, Otavio Salvador wrote: > - we have a different (newer) version
I think particularly for point updates we should be able to minimize the pain if the base recipes are set up well. > - we use eglnative mostly, though we might start wanting to use glx > under qemu for testing (subject to getting a suitable mesa) This is the crux of the difficulties with cogl/clutter. In Guacamayo I need to be able to use both eglnative and glx. I prefer eglnative + gles2, because I only need a single clutter based app running and the X11 overhead is not negligible, but on intel HW I have not been able to get this working satisfactorily in the past, so ended up using GLX for the likes of atom-pc and NUC. The solution I came up with is to predefine a bunch common configure+depends+rdepends sets in the clutter/cogl includes (there is only a finite number of configurations that makes sense, though my recipes do not cover them all), and then in a Guacamayo-specific bbappend choose a suitable configuration on per-machine basis. > - we have a slightly funky 2-stage bootstrap process for cogl in order > to break the dependency cycle with cairo; this involves hacks to the > recipes for cogl, cairo, pango and harfbuzz (at least) which I suspect > would not be very palatable to oe-core. I have never run into this, is this with recent cogls? > The net result of all this is that, whenever I try to factor out a set > of stuff that's "generic clutter" and could go into oe-core, I end up > with recipes that have virtually nothing in common with what we're > actually using and consequently don't actually solve any of my problems. I don't think we can create a set of recipes that 'just work' for everyone, but we can have recipes that minimal effort and that also provide sensible defaults for the common machines out there. There are some broader issues here though that need thought, particularly, a bbappend should be a method of last resort, it would be nice have a feature mechanism to ease the configuration. But distro features are of no use here because it is not possible to differentiate packages with different configs based on DF; machine features don't have this limitation, but are the wrong place for this, plus it is entirely conceivable you might want be able to build different configs for the same machine on the same tmp dir (I use pseudo-machines for this, like atom-egl, but that is just a nasty hack). Tomas -- http://sleepfive.com _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
