[OE-core] [PATCH 0/1] Clutter-1.6 fix

[Denys Dmytriyenko]

On Sun, Apr 10, 2011 at 08:12:45AM -0700, Koen Kooi wrote:
> 
> 
> Op 9 apr. 2011 om 18:52 heeft Denys Dmytriyenko <denis at denix.org> het volgende geschreven:
> 
> > 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 <josh at 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...
> 
> It is already in :)

Ah, I see now. Your original post made it sound like it was still OE-only 
feature not available in oe-core... :)

> fwiw, atmel is using it as well for at91

-- 
Denys