On Wed, 2013-05-15 at 16:28 -0300, Otavio Salvador wrote: > I agree but it seems it hadn't succeed in this specific case until > now. I personally think Clutter will benefit from getting a specific > place to look at and it does seem multiple people has been adding > Clutter recipes in their internal layers (Phil for example, Guacamayo > project and so on).
I did actually have a couple of goes at trying to factor out some of our local changes to the clutter recipes for submission to oe-core, but on each occasion I gave up because the effort seemed to outweigh the benefits. For what it's worth, some of the ways in which our local recipes diverge from what's in oe-core are: - we have a different (newer) version - we build from a local git checkout, srctree-style, because our sources are significantly patched compared to upstream - we use eglnative mostly, though we might start wanting to use glx under qemu for testing (subject to getting a suitable mesa) - 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. 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. However, I have no doubt that someone cleverer than me could do a better job of it. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core