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. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core