[meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Koen Kooi]

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
index b5a3c16..4895893 100644
--- a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
+++ b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
@@ -1,7 +1,8 @@
-QT_GLFLAGS_omap3 = "-egl"
+QT_GLFLAGS_omap3 = "-opengl es2 "
 DEPENDS_append_omap3 = " libgles-omap3"
+DEPENDS_append_ti33x = " libgles-omap3"
 
 # Needed by kdelibs
 QT_DISTRO_FLAGS = "-accessibility -sm"
 
-PRINC := "${@int(PRINC) + 1}"
\ No newline at end of file
+PRINC := "${@int(PRINC) + 2}"
-- 
1.7.7.6

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Samuel Stirtzel]

2012/4/23 Koen Kooi <koen@dominion.thruhere.net>:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> index b5a3c16..4895893 100644
> --- a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> +++ b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> @@ -1,7 +1,8 @@
> -QT_GLFLAGS_omap3 = "-egl"
> +QT_GLFLAGS_omap3 = "-opengl es2 "
>  DEPENDS_append_omap3 = " libgles-omap3"
> +DEPENDS_append_ti33x = " libgles-omap3"
>
>  # Needed by kdelibs
>  QT_DISTRO_FLAGS = "-accessibility -sm"
>
> -PRINC := "${@int(PRINC) + 1}"
> \ No newline at end of file
> +PRINC := "${@int(PRINC) + 2}"
> --
> 1.7.7.6
>


Applied, thanks.

You don't need QT_GLFLAGS_ti33x = "-opengl es2 " in the .bbappend?


-- 
Regards
Samuel

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Paul Eggleton]

On Monday 23 April 2012 16:25:35 Koen Kooi wrote:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend index b5a3c16..4895893
> 100644
> --- a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> +++ b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> @@ -1,7 +1,8 @@
> -QT_GLFLAGS_omap3 = "-egl"
> +QT_GLFLAGS_omap3 = "-opengl es2 "
>  DEPENDS_append_omap3 = " libgles-omap3"
> +DEPENDS_append_ti33x = " libgles-omap3"
> 
>  # Needed by kdelibs
>  QT_DISTRO_FLAGS = "-accessibility -sm"
> 
> -PRINC := "${@int(PRINC) + 1}"
> \ No newline at end of file
> +PRINC := "${@int(PRINC) + 2}"

Can we avoid this machine-specific stuff creeping into software layers? At least 
in this case we're appending something in OE-Core so there should be no 
problem with this appearing in an append in the BSP(s).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 23-04-12 17:46, Paul Eggleton schreef:
> On Monday 23 April 2012 16:25:35 Koen Kooi wrote:
>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> --- 
>> recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++-- 1 files
>> changed, 3 insertions(+), 2 deletions(-)
>> 
>> diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend 
>> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend index
>> b5a3c16..4895893 100644 ---
>> a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend +++
>> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend @@ -1,7 +1,8 @@ 
>> -QT_GLFLAGS_omap3 = "-egl" +QT_GLFLAGS_omap3 = "-opengl es2 " 
>> DEPENDS_append_omap3 = " libgles-omap3" +DEPENDS_append_ti33x = "
>> libgles-omap3"
>> 
>> # Needed by kdelibs QT_DISTRO_FLAGS = "-accessibility -sm"
>> 
>> -PRINC := "${@int(PRINC) + 1}" \ No newline at end of file +PRINC :=
>> "${@int(PRINC) + 2}"
> 
> Can we avoid this machine-specific stuff creeping into software layers?
> At least in this case we're appending something in OE-Core so there
> should be no problem with this appearing in an append in the BSP(s).

Have a look at what was discussed in the "[meta-kde] Test images (was: Re:
[OE-core] RFC: Porting KDE Plasma Active (WIP))" thread

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPla/zAAoJEHZqAkdh1vT63cAP/0uMXlmsoAgrlN3LpHrB0Qw5
wRfJoku9dqYY8rx3rNUZewwVL3VQsUyZWItCfCT2HfHhaFdd6XDMMaka8Vq7BF8R
eH5reueGTbRlDXTFQ7c3BeCmI4af4ThvPDTPogNJXzHPg/7pMb94Z4TmBrZwgz9t
Clz/UntDusu6L+k347yZ9Dulsnisw/65Pt4U3CHbRceEwR5dHBpO64XDyCJpKKUe
ubdyxWcJtlKRGIr+LqP/G/SWZGgtHKJVzDKby3gxPsdvnML6Gh2o3eXIwfDKnGpv
7Yq1n7Zh1xAXJvwGLifd6w7NdOFRbqyUtYXnebWm4jAqZa9kTMmT/GQPdYM5Ykfb
Twlxlczkzrj1acKHNyiI61wgd8yoB7B/h2gtyyYacPFPntSOnePGvU+N/Zfxi39Z
61zRQlw+0Gtg4DLQVp0egea2G7RhopfK6JaDyioW/wawHPXEQAOSVQhhznCxoEt4
fASr62lSM/o1IKPRdjt810Oji93PTdwe0Fe7IWtpx/tGku9wsedxqKQJmxaFwcmf
/Vp6wFchhqda8wTTFVqTMlv2I9Tm5if2FKVes7Qob5FGFyok11jHCTLH2uKSMA/0
MsuqybuJgVh2EIqW26feGNQoYJQIkO/jjWEyCIhnRykliCS9HeQdFgPpt9yrPpDT
oocoaz7/GMLaffiJP7yD
=E/KO
-----END PGP SIGNATURE-----

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Paul Eggleton]

On Monday 23 April 2012 21:39:36 Koen Kooi wrote:
> Op 23-04-12 17:46, Paul Eggleton schreef:
> > On Monday 23 April 2012 16:25:35 Koen Kooi wrote:
> >> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> ---
> >> recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++-- 1 files
> >> changed, 3 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
> >> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend index
> >> b5a3c16..4895893 100644 ---
> >> a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend +++
> >> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend @@ -1,7 +1,8 @@
> >> -QT_GLFLAGS_omap3 = "-egl" +QT_GLFLAGS_omap3 = "-opengl es2 "
> >> DEPENDS_append_omap3 = " libgles-omap3" +DEPENDS_append_ti33x = "
> >> libgles-omap3"
> >> 
> >> # Needed by kdelibs QT_DISTRO_FLAGS = "-accessibility -sm"
> >> 
> >> -PRINC := "${@int(PRINC) + 1}" \ No newline at end of file +PRINC :=
> >> "${@int(PRINC) + 2}"
> > 
> > Can we avoid this machine-specific stuff creeping into software layers?
> > At least in this case we're appending something in OE-Core so there
> > should be no problem with this appearing in an append in the BSP(s).
> 
> Have a look at what was discussed in the "[meta-kde] Test images (was: Re:
> [OE-core] RFC: Porting KDE Plasma Active (WIP))" thread

Yes, I understand why it was added, but (as I'm sure you're aware) one of the 
reasons why we did the layer split was to avoid having numbers of machine-
specific overrides appearing in generic recipes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Samuel Stirtzel]

2012/4/23 Paul Eggleton <paul.eggleton@linux.intel.com>:
> On Monday 23 April 2012 21:39:36 Koen Kooi wrote:
>> Op 23-04-12 17:46, Paul Eggleton schreef:
>> > On Monday 23 April 2012 16:25:35 Koen Kooi wrote:
>> >> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net> ---
>> >> recipes-misc-support/qt4-x11-free_4.8.0.bbappend |    5 +++-- 1 files
>> >> changed, 3 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend
>> >> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend index
>> >> b5a3c16..4895893 100644 ---
>> >> a/recipes-misc-support/qt4-x11-free_4.8.0.bbappend +++
>> >> b/recipes-misc-support/qt4-x11-free_4.8.0.bbappend @@ -1,7 +1,8 @@
>> >> -QT_GLFLAGS_omap3 = "-egl" +QT_GLFLAGS_omap3 = "-opengl es2 "
>> >> DEPENDS_append_omap3 = " libgles-omap3" +DEPENDS_append_ti33x = "
>> >> libgles-omap3"
>> >>
>> >> # Needed by kdelibs QT_DISTRO_FLAGS = "-accessibility -sm"
>> >>
>> >> -PRINC := "${@int(PRINC) + 1}" \ No newline at end of file +PRINC :=
>> >> "${@int(PRINC) + 2}"
>> >
>> > Can we avoid this machine-specific stuff creeping into software layers?
>> > At least in this case we're appending something in OE-Core so there
>> > should be no problem with this appearing in an append in the BSP(s).
>>
>> Have a look at what was discussed in the "[meta-kde] Test images (was: Re:
>> [OE-core] RFC: Porting KDE Plasma Active (WIP))" thread
>
> Yes, I understand why it was added, but (as I'm sure you're aware) one of the
> reasons why we did the layer split was to avoid having numbers of machine-
> specific overrides appearing in generic recipes.
>
> Cheers,
> Paul

For this .bbappend it is no problem, over time the machine specific
stuff will disappear (it is only there for testing).

But I see a problem with kde-workspace [1].
If it should build kwin_gles then it depends on libgles, but not every
machine has libgles.
It would be no problem if virtual/libgl is used but that don't work
for machines that use virtual/egl.

Or is there a way to build time recommend something instead of depending on it?


[1] https://gitorious.org/openembedded-core-layers/meta-kde/blobs/master/recipes-kde-base/kde-workspace_git.bb#line8
-- 
Regards
Samuel

Re: [meta-kde][PATCH] qt4-x11-free 4.8.0 bbappend: fix GLES configure switch and turn it on for AM335x SoCs as well

[Paul Eggleton]

On Tuesday 24 April 2012 15:54:17 Samuel Stirtzel wrote:
> For this .bbappend it is no problem, over time the machine specific
> stuff will disappear (it is only there for testing).
> 
> But I see a problem with kde-workspace [1].
> If it should build kwin_gles then it depends on libgles, but not every
> machine has libgles.
> It would be no problem if virtual/libgl is used but that don't work
> for machines that use virtual/egl.
> 
> Or is there a way to build time recommend something instead of depending on
> it?

You can add an RRECOMMENDS, however if the library is already dynamically 
linked to some other library then there will be a hard dependency on that 
library which via the shlibdeps code in package.bbclass will become an 
RDEPENDS; nothing in our system can really work around that if it's integrated 
into a single binary (or indivisible group of binaries).

It seems to me that either the functionality needs to be split out into its 
own separate package which can be pulled in optionally (if possible), or more 
likely in this case the recipe needs to become machine-specific and be 
dependent on some item in MACHINE_FEATURES.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre