[PATCH 0/1] Clutter-1.6 fix

[PATCH 0/1] Clutter-1.6 fix

[Joshua Lock]

From: Joshua Lock <josh@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?

Pull URL: git://git.openembedded.org/openembedded-core-contrib
  Branch: josh/clutter
  Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/clutter

Thanks,
    Joshua Lock <josh@linux.intel.com>
---


Joshua Lock (1):
  clutter-1.6: fix tarball md5sum and add json-glib to dependencies

 meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

-- 
1.7.4.1

[PATCH 1/1] clutter-1.6: fix tarball md5sum and add json-glib to dependencies

[Joshua Lock]

From: Joshua Lock <josh@linux.intel.com>

* As of Clutter 1.5.2 the project no longer ships an internal version of
json-glib so we must explicitly add it to the DEPENDS.
* Fix the SRC_URI[md5sum]

Signed-off-by: Joshua Lock <josh@linux.intel.com>
---
 meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb b/meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb
index 7ead5f9..ffcc42d 100644
--- a/meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb
+++ b/meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb
@@ -2,6 +2,9 @@ require recipes-graphics/clutter/clutter.inc
 
 PR = "r0"
 
+# Internal json-glib was removed in Clutter 1.5.2
+STDDEPENDS += "json-glib"
+
 PACKAGES =+ "${PN}-examples"
 FILES_${PN}-examples = "${bindir}/test-* ${pkgdatadir}/redhand.png"
 
@@ -14,12 +17,10 @@ S = "${WORKDIR}/clutter-1.6.8"
 
 BASE_CONF += "--disable-introspection"
 
-EXTRA_OECONF += "--with-json=check"
-
 do_configure_prepend () {
 	# Disable DOLT
 	sed -i -e 's/^DOLT//' ${S}/configure.ac
 }
 
-SRC_URI[md5sum] = "5a3c6d8414d4e286aba0a936f344c9b1""
+SRC_URI[md5sum] = "9eedac4216f709a9f144940d24bfbb3e"
 SRC_URI[sha256sum] = "cc147b8e7e62ed4b9b8a83df3db9788cf37db0c83970ba876228433f32bda442"
-- 
1.7.4.1

Re: [PATCH 0/1] Clutter-1.6 fix

[Koen Kooi]

Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven:

> From: Joshua Lock <josh@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.

regards,

Koen

Re: [PATCH 0/1] Clutter-1.6 fix

[Joshua Lock]

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

Regards,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Re: [PATCH 0/1] Clutter-1.6 fix

[Denys Dmytriyenko]

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

Re: [PATCH 0/1] Clutter-1.6 fix

[Koen Kooi]

Op 9 apr. 2011 om 18:52 heeft Denys Dmytriyenko <denis@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@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 :)

fwiw, atmel is using it as well for at91




> 
> -- 
> Denys
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [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@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@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