On Wed, Apr 06, 2011 at 12:07:52PM +0100, Joshua Lock wrote: > On Mon, 2011-04-04 at 15:39 +0200, Koen Kooi wrote: > > Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven: > > > > > From: Joshua Lock <j...@linux.intel.com> > > > > > > I found a couple of issues with the Clutter 1.6 recipes I submitted > > > recently > > > which I've addressed in the attached patch. > > > > > > As an aside I've noticed that we have a COMPATIBLE_MACHINE line in > > > clutter.inc, I think we're going to need to find a more suitable mechanism > > > for specifying compatible machines for this recipe set going forwards. > > > > > > Any ideas? Perhaps some MACHINE_FEATURE which must exist for Clutter (and > > > other GL dependent recipes) to build? > > > > What we did in OE .dev was: > > > > 1) introduce SOC_FAMILY to group, well, SOC families (e.g. OMAP3) > > 2) Extend base.bbclass to allow COMPATIBLE_MACHINE = $SOC_FAMILY. > > 3) Add COMPATIBLE_MACHINE = omap3 to the GLES recipes > > 4) DEPENDS_omap3 = libgles-omap3 in clutter.inc > > > > So for machines in the omap3 class it will build libgles-omap3 and not > > for others. So the compatibility is defined at the GL level instead of > > the clutter level. > > Thanks for sharing Koen. This sounds like a reasonable approach. I'd be > curious to hear if there are any objections before I try and work up a > patch series.
FWIW, it would be very nice to bring SOC_FAMILY feature from OE to oe-core, as it's being heavily used in many TI recipes, not just omap3... -- Denys _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core