Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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 +, Phil Blundell wrote:
On Thu, 2011-12-08 at 16:55 +, 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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
Op 8 dec. 2011, om 10:34 heeft Xiaofeng Yan het volgende geschreven:
From: Xiaofeng Yan xiaofeng@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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@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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
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@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
On Thu, 2011-12-08 at 16:55 +, 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.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
On Thu, 2011-12-08 at 17:12 +, Phil Blundell wrote:
On Thu, 2011-12-08 at 16:55 +, 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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
Op 8 dec. 2011, om 22:59 heeft Richard Purdie het volgende geschreven:
On Thu, 2011-12-08 at 17:12 +, Phil Blundell wrote:
On Thu, 2011-12-08 at 16:55 +, 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?
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 04/10] gtk.inc: add feature based on directfb
Op 7 dec. 2011, om 09:58 heeft Xiaofeng Yan het volgende geschreven: From: Xiaofeng Yan xiaofeng@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. So what happens when I put both directfb and x11 in DISTRO_FEATURES? signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
