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

On 16/05/13 11:35, Phil Blundell wrote:
> 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.

Yep, that's one of the things I need to clean up in my own recipes.


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

This would probably merit some sort of cogl-initial recipe to add.


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

I originally went down the PN route, but that meant having to specify
preferred providers and in my use case the sole criterion was the
MACHINE. But for a generic solution, it's probably necessary to have
some PN mechanism in place, maybe the keys in PACKAGECONFIG could be
used to automatically create a mangled PN for non-standard configs.

Tomas