| Submitter | Koen Kooi |
|---|---|
| Date | April 23, 2012, 2:25 p.m. |
| Message ID | <1335191135-6762-1-git-send-email-koen@dominion.thruhere.net> |
| Download | mbox | patch |
| Permalink | /patch/26339/ |
| State | Accepted |
| Headers | show |
Comments
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?
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
-----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-----
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
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
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
Patch
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}"
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(-)