[OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer

Phil Blundell pb at pbcl.net
Thu May 16 10:35:55 UTC 2013


On Thu, 2013-05-16 at 10:01 +0100, Tomas Frydrych wrote:
> 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.

Right, that sounds fairly reasonable.  Or one could presumably use
PACKAGECONFIG for this sort of thing.

> > - 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?

It's because we build Cairo with the cogl backend enabled.  That
introduces a dependency of cairo on cogl (obviously), which is a problem
because cogl-pango needs pango, which needs harfbuzz, which needs cairo.
So what we do is build cogl initially with pango disabled, then use that
to compile cairo and the rest of the stack, and then finally build the
"real" cogl with everything enabled.

Obviously the other option would be to build cairo twice, firstly
without cogl and the second time with it.  I don't think there's much to
choose between the two.

> 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).

This is something that's just fundamentally difficult in OE; there
simply isn't any namespace to express that degree of freedom.  DISTRO is
essentially invariant for any given tmpdir, and the hierarchy in there
reflects MACHINE and PN.  So, if you want to build the same package with
a different configuration then either MACHINE or PN is going to have to
change.  Traditionally of course it's been PN that changes in this
situation.

p.






More information about the Openembedded-core mailing list