Patchwork [04/10] gtk.inc: add feature based on directfb

login
register
mail settings
Submitter Xiaofeng Yan
Date Dec. 8, 2011, 9:34 a.m.
Message ID <7ceb01f6db6edfad6c78c5a7ebc685c23bb11358.1323327959.git.xiaofeng.yan@windriver.com>
Download mbox | patch
Permalink /patch/16507/
State New
Headers show

Comments

Xiaofeng Yan - Dec. 8, 2011, 9:34 a.m.
From: Xiaofeng Yan <xiaofeng.yan@windriver.com>

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 <xiaofeng.yan@windriver.com>
---
 meta/recipes-gnome/gtk+/gtk+.inc |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)
Koen Kooi - Dec. 8, 2011, 10:14 a.m.
Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:

> From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
> 
> 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.


> 
> [YOCTO #1674]
> 
> Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
> ---
> meta/recipes-gnome/gtk+/gtk+.inc |   13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
> index 1d8f4a6..0319916 100644
> --- a/meta/recipes-gnome/gtk+/gtk+.inc
> +++ b/meta/recipes-gnome/gtk+/gtk+.inc
> @@ -9,9 +9,16 @@ LICENSE = "LGPLv2 & LGPLv2+ & LGPLv2.1+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
> 
> SECTION = "libs"
> -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
> 
> -- 
> 1.7.0.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Dec. 8, 2011, 2:39 p.m.
On Thu, 2011-12-08 at 11:14 +0100, Koen Kooi wrote:
> Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:
> 
> > From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
> > 
> > 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", 

The answer to that question seems to be that you will get undefined
behaviour.  Both PACKAGECONFIG flags will match so you'll get the
configure options for both of them, but the packageconfig mechanism
doesn't appear to guarantee what the ordering will be.  (You might
expect that it would be the order of the entries in PACKAGECONFIG itself
but, from a quick look at the code, that doesn't appear to be the case.)

So, you'll end up with both sets of things in DEPENDS and either:

--with-x=yes --with-gdktarget=x11 --with-gdktarget=directfb

or

--with-gdktarget=directfb --with-x=yes --with-gdktarget=x11

in EXTRA_OECONF but there doesn't seem to be any obvious way to predict
which it'll be.

It would be nice if there was a way to declare PACKAGECONFIG options as
conflicting with each other so that you'd get a diagnostic if you tried
to turn both on.  But there's no mechanism to support that at present
and it doesn't seem like it would merit ad-hoc python hacks in the gtk+
recipe.

p.
Richard Purdie - Dec. 8, 2011, 4:55 p.m.
On Thu, 2011-12-08 at 11:14 +0100, Koen Kooi wrote:
> Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:
> 
> > From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
> > 
> > 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.

This comes down to a policy decision I guess and I'm not sure there is a
clear cut answer.

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.

My personal take on that is that it depends how ugly the result is and
what demand there is for it. I do consider having the separate -directfb
recipes to be ugly and if we only need a cairo variant that might be ok,
if we need a ton of recipe forks I'd be much less keen. Doing separate
recipes like that is error prone and often not done well.

So can anyone tell me for sure exactly how many recipes would need
-directfb variants?

Cheers,

Richard
Phil Blundell - Dec. 8, 2011, 5:12 p.m.
On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote:
> 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.

p.
Richard Purdie - Dec. 8, 2011, 9:59 p.m.
On Thu, 2011-12-08 at 17:12 +0000, Phil Blundell wrote:
> On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote:
> > 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.  

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.

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

Cheers,

Richard
Koen Kooi - Dec. 9, 2011, 6:51 a.m.
Op 8 dec. 2011, om 22:59 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-12-08 at 17:12 +0000, Phil Blundell wrote:
>> On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote:
>>> 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.  
> 
> 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.
> 
>> 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?
Phil Blundell - Dec. 9, 2011, 10:08 a.m.
On Fri, 2011-12-09 at 07:51 +0100, Koen Kooi wrote:
> 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?

p.
Koen Kooi - Dec. 9, 2011, 10:25 a.m.
Op 9 dec. 2011, om 11:08 heeft Phil Blundell het volgende geschreven:

> On Fri, 2011-12-09 at 07:51 +0100, Koen Kooi wrote:
>> 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. Unless OE-core really wants a distro to select either directfb or x11, but not both. In that case it should BBMASK out directfb if 'x11' is in distro features and vice versa.
Phil Blundell - Dec. 9, 2011, 10:30 a.m.
On Fri, 2011-12-09 at 11:25 +0100, Koen Kooi wrote:
> 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.

Well, you can set:

# support both graphical backends where possible
DISTRO_FEATURES = "directfb x11"

# for gtk+ 2.x, have to pick either x11 or directfb not both
PACKAGECONFIG_pn-gtk+ = "x11"

in your distro config.  I don't think that one extra line really counts
as a "ton of hoops", and if you aren't using gtk+ 2.0 then you can just
leave it out.

p.
Richard Purdie - Dec. 9, 2011, 10:34 a.m.
On Fri, 2011-12-09 at 07:51 +0100, Koen Kooi wrote:
> Op 8 dec. 2011, om 22:59 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-12-08 at 17:12 +0000, Phil Blundell wrote:
> >> On Thu, 2011-12-08 at 16:55 +0000, Richard Purdie wrote:
> >>> 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.  
> > 
> > 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.
> > 
> >> 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?

I think that is reasonable.

Cheers,

Richard

Patch

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index 1d8f4a6..0319916 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -9,9 +9,16 @@  LICENSE = "LGPLv2 & LGPLv2+ & LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
 
 SECTION = "libs"
-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