gtk+-directfb: The patches to run gtk over directfb

From: Xiaofeng Yan <[email protected]>

gtk run over x11 at current OE-core. If gtk want to run over directfb, then \
the configuration related to x11 should be disabled and directfb should be enabled.

[YOCTO #1674]

Signed-off-by Xiaofeng Yan <[email protected]>

---
meta/recipes-gnome/gtk+/gtk+.inc | 13 ++++++++++---

1 files changed, 10 insertions(+), 3 deletions(-)

meta/recipes-gnome/gtk+/gtk+.inc +0 -0

index 1d8f4a6..0319916 100644
@@ -9,9 +9,16 @@ LICENSE = "LGPLv2 & LGPLv2+ & LGPLv2.1+"

LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"

SECTION = "libs"

meta/recipes-gnome/gtk+/gtk+.inc +10 -3

-DEPENDS = "glib-2.0 pango atk jpeg libpng libxext libxcursor \
-           gtk-doc-native docbook-utils-native libxrandr libgcrypt \
-           libxdamage libxrender libxcomposite cairo gdk-pixbuf"
+
+X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr libxdamage libxrender libxcomposite"
+DEPENDS = "glib-2.0 pango atk jpeg libpng gtk-doc-native gdk-pixbuf-native docbook-utils-native \
+ libgcrypt cairo gdk-pixbuf"
+
+PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
+ ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)}"
+
+PACKAGECONFIG[x11] = "--with-x=yes --with-gdktarget=x11,--with-x=no,${X11DEPENDS}"
+PACKAGECONFIG[directfb] = "--with-gdktarget=directfb,,directfb"

inherit autotools pkgconfig

Signature · 7 lines

1.7.0.4


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

Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:

Quoted 4 lines

From: Xiaofeng Yan <[email protected]>

gtk run over x11 at current OE-core. If gtk want to run over directfb, then \
the configuration related to x11 should be disabled and directfb should be enabled.

Since I still can't get an answer to "what happens when you enable both x11 and directfb as distro features",

Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:

Quoted 4 lines

From: Xiaofeng Yan <[email protected]>

gtk run over x11 at current OE-core. If gtk want to run over directfb, then \
the configuration related to x11 should be disabled and directfb should be enabled.

Since I still can't get an answer to "what happens when you enable both x11 and directfb as distro features", let me ask a different question:

Why don't you do it like we did for gtk-directfb in OE-classic? add a cairo-directfb and a gtk-directfb, done.

The question is whether it makes sense to have directfb and X based gtk in the same builds and package feeds or not. I can see that it might be desired and that it likely is possible.

Quoted 3 lines · Richard Purdie

The question is whether it makes sense to have directfb and X based gtk in the same builds and package feeds or not. I can see that it might be desired and that it likely is possible.

This is true, though there's nothing to stop a distro that particularly wants this from inventing their own stub recipes which just set PACKAGECONFIG appropriately and then require the generic version. So it's really just a question of what we want to be the default in oe-core.

Also note that, although you can parallel install multiple versions of the gtk+ runtime on the target system, if you want the build system to be deterministic then (in the absence of per-recipe sysroot construction) you need some way to decide which one gets to provide the gtk+-2.0.pc that other recipes will build against. (The different targets have different library sonames so you can't just swap them out at run time: a given binary will remain coupled to the particular Gtk variant that it was compiled against.) And if the two variants could conceivably be different versions of GTK then you also need a way to deconflict ${includedir}/gtk-2.0.

So it isn't quite as simple as just having the two recipes, there is a bit of extra policy involved as well. And of course there would be all the normal overhead in terms of parse time, memory footprint and maintenance burden associated with having more recipes.

So, in light of all the above plus the fact that everything is different with Gtk+3 anyway, my preference for supporting directfb on gtk+2 in oe-core would be to use PACKAGECONFIG and not have separate recipe files.

Quoted 22 lines · Richard Purdie

Quoted 3 lines

The question is whether it makes sense to have directfb and X based gtk in the same builds and package feeds or not. I can see that it might be desired and that it likely is possible.

This is true, though there's nothing to stop a distro that particularly wants this from inventing their own stub recipes which just set PACKAGECONFIG appropriately and then require the generic version. So it's really just a question of what we want to be the default in oe-core.

Also note that, although you can parallel install multiple versions of the gtk+ runtime on the target system, if you want the build system to be deterministic then (in the absence of per-recipe sysroot construction) you need some way to decide which one gets to provide the gtk+-2.0.pc that other recipes will build against. (The different targets have different library sonames so you can't just swap them out at run time: a given binary will remain coupled to the particular Gtk variant that it was compiled against.) And if the two variants could conceivably be different versions of GTK then you also need a way to deconflict ${includedir}/gtk-2.0.

Quoted 4 lines

So it isn't quite as simple as just having the two recipes, there is a bit of extra policy involved as well. And of course there would be all the normal overhead in terms of parse time, memory footprint and maintenance burden associated with having more recipes.

This is the key detail I was missing. I thought they just might have been a drop in replacement.

That isn't the case so this makes the choice easier, I think separate recipes don't make sense based on this.

Quoted 4 lines

So, in light of all the above plus the fact that everything is different with Gtk+3 anyway, my preference for supporting directfb on gtk+2 in oe-core would be to use PACKAGECONFIG and not have separate recipe files.

Agreed, given the above.

So to be safe and give other directfb implementations a change, can this PACKAGECONFIG option be named 'gtk-directfb' in DISTRO_FEATURES?

Quoted 2 lines

So to be safe and give other directfb implementations a change, can this PACKAGECONFIG option be named 'gtk-directfb' in DISTRO_FEATURES?

I don't think I quite understand what you're saying there. Can you expand on why this would be a good thing?

gtk 2.x is one of the few places where directfb/x11/whatever conflict, so if I want directfb support for sane things (gtk 3.x, qt, etc) the current patch will make me jump through a ton of hoops.

Op 8 dec. 2011, om 22:59 heeft Richard Purdie het volgende geschreven:

Quoted 39 lines · Phil Blundell

Quoted 22 lines · Richard Purdie

Quoted 3 lines

The question is whether it makes sense to have directfb and X based gtk in the same builds and package feeds or not. I can see that it might be desired and that it likely is possible.

This is true, though there's nothing to stop a distro that particularly wants this from inventing their own stub recipes which just set PACKAGECONFIG appropriately and then require the generic version. So it's really just a question of what we want to be the default in oe-core.

Also note that, although you can parallel install multiple versions of the gtk+ runtime on the target system, if you want the build system to be deterministic then (in the absence of per-recipe sysroot construction) you need some way to decide which one gets to provide the gtk+-2.0.pc that other recipes will build against. (The different targets have different library sonames so you can't just swap them out at run time: a given binary will remain coupled to the particular Gtk variant that it was compiled against.) And if the two variants could conceivably be different versions of GTK then you also need a way to deconflict ${includedir}/gtk-2.0.

Quoted 4 lines

So it isn't quite as simple as just having the two recipes, there is a bit of extra policy involved as well. And of course there would be all the normal overhead in terms of parse time, memory footprint and maintenance burden associated with having more recipes.

This is the key detail I was missing. I thought they just might have been a drop in replacement.

That isn't the case so this makes the choice easier, I think separate recipes don't make sense based on this.

Quoted 4 lines

So, in light of all the above plus the fact that everything is different with Gtk+3 anyway, my preference for supporting directfb on gtk+2 in oe-core would be to use PACKAGECONFIG and not have separate recipe files.

Quoted 1 line

Agreed, given the above.

So to be safe and give other directfb implementations a change, can this PACKAGECONFIG option be named 'gtk-directfb' in DISTRO_FEATURES?

From: Xiaofeng Yan <[email protected]>

Add demos for checking whether gtk+ run over directfb successfully or not.

[YOCTO #1674]

Signed-off-by Xiaofeng Yan <[email protected]>

---
 meta/recipes-gnome/gtk+/gtk+_2.24.8.bb |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

meta/recipes-gnome/gtk+/gtk+_2.24.8.bb +4 -2

index fb88979..9119d16 100644
@@ -9,12 +9,14 @@ SRC_URI = "http://download.gnome.org/sources/gtk+/2.24/gtk+-${PV}.tar.bz2 \
            file://run-iconcache.patch \
            file://configure-nm.patch \
            file://hardcoded_libtool.patch \
-           file://no-demos.patch \
+           ${@base_contains('DISTRO_FEATURES', 'directfb', '','${NODEMOS_SRC_URI}', d)} \
            file://cellrenderer-cairo.patch;striplevel=0 \
            file://toggle-font.diff;striplevel=0 \
            file://0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch \
            file://doc-fixes.patch \
 	  "
+NODEMOS_SRC_URI = "file://no-demos.patch"
+
 # TO MERGE
 #           file://entry-cairo.patch;striplevel=0
 #           file://filesystem-volumes.patch

@@ -27,7 +29,7 @@ SRC_URI = "http://download.gnome.org/sources/gtk+/2.24/gtk+-${PV}.tar.bz2 \
 #        file://combo-arrow-size.patch;striplevel=0
 #            file://configurefix.patch
 
-PR = "r0"
+PR = "r1"
 
 SRC_URI[md5sum] = "0413187f7e596aef00ccd1b54776ff03"
 SRC_URI[sha256sum] = "ac2325a65312922a6722a7c02a389f3f4072d79e13131485cc7b7226e2537043"

+IMAGE_INSTALL += "\
+       ${POKY_BASE_INSTALL} \

Hi,

2011/12/8 Xiaofeng Yan<[email protected]>:
[snip]

meta/recipes-graphics/images/core-image-gtk-directfb.bb line 17

Quoted 2 lines

meta/recipes-graphics/images/core-image-gtk-directfb.bb new file +2 -0

+IMAGE_INSTALL += "\
+       ${POKY_BASE_INSTALL} \

I'm just curious, is this a legitimate OE-Core variable?