Re: proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer

[Tomas Frydrych <tf+lists.yocto@r-finger.com>]

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