Clutter-1.6 fix

PATCH In review Joshua Lock 3 participants 7 messages Apr 4, 2011 – Apr 11, 2011

lore

Share & tools

lore

Joshua Lock

author

2011-04-04 13:33 UTC #0 lore raw

cover Clutter-1.6 fix

From: Joshua Lock <[email protected]>

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 <[email protected]>
---

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(-)

Signature · 1 line

1.7.4.1

Joshua Lock

author

2011-04-04 13:33 UTC #1 lore raw

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

From: Joshua Lock <[email protected]>

* 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 <[email protected]>

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

meta/recipes-graphics/clutter/clutter-1.6_1.6.8.bb +4 -3

index 7ead5f9..ffcc42d 100644
@@ -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"

Signature · 1 line

1.7.4.1

Koen Kooi

2011-04-04 13:41 UTC #2 lore raw

In reply to Joshua Lock

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

Quoted 11 lines

From: Joshua Lock <[email protected]>
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

Joshua Lock

author

2011-04-06 11:10 UTC #3 lore raw

Quoted 16 lines · Koen Kooi

Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven:
Quoted 11 lines
From: Joshua Lock <[email protected]>
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:

Quoted 8 lines

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

Signature · 3 lines

Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre

Denys Dmytriyenko

2011-04-10 02:54 UTC #4 lore raw

Quoted 22 lines · Joshua Lock

Quoted 21 lines · Koen Kooi
Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven:
Quoted 11 lines
From: Joshua Lock <[email protected]>
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

Quoted 7 lines

Quoted 3 lines
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...

Signature · 1 line

Denys

Koen Kooi

2011-04-10 15:15 UTC #5 lore raw

Op 9 apr. 2011 om 18:52 heeft Denys Dmytriyenko <[email protected]> het volgende geschreven:

Quoted 27 lines · Joshua Lock

Quoted 26 lines · Koen Kooi
Quoted 24 lines
Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven:
Quoted 11 lines
From: Joshua Lock <[email protected]>
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.

Quoted 6 lines

Quoted 3 lines
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

Quoted 8 lines

Signature · 7 lines

-- 
Denys

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Denys Dmytriyenko

2011-04-11 05:18 UTC #6 lore raw

Quoted 31 lines · Koen Kooi

Op 9 apr. 2011 om 18:52 heeft Denys Dmytriyenko <[email protected]> het volgende geschreven:
Quoted 27 lines · Joshua Lock
Quoted 26 lines · Koen Kooi
Quoted 24 lines
Op 4 apr 2011, om 15:31 heeft Joshua Lock het volgende geschreven:
Quoted 11 lines
From: Joshua Lock <[email protected]>
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.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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... :)

Quoted 1 line

fwiw, atmel is using it as well for at91

Signature · 1 line

Denys