making qt5 package machine specific

making qt5 package machine specific

[Nicolas Dechesne]

hi,

we are building a product/distro with qt5 with support for various SoC. the
way qt5 recipes are designed, it kind of forces the resulting packages to
be  <machine> specific, not <arch> specific.

first each <machine> has a different provider for GL/GLES and it impacts
the RDEPENDS, on top of that we have machine specific patches in Qt5 in
each of our BSP layer, whether we like it or not, that's a reality that we
cannot have the very same Qt5 config + source code for all platforms.

so we end up with many  <qt pkgs>-<arch> which are <machine> specific, not
<arch>, and it messes up badly with sstate for example, especially when
cleaning up the sstate (e.g. using sstate-cache-management -d).

so i have a couple of questions:

 - are we doing something really wrong here? or are we getting issues that
anyone would get when trying to have a OE based product with Qt5 and
multiple machines from the same <arch>?

 - assuming this is a typical use case... i wish there was an easy
mechanism to 'mark' all Qt5 packages as PACKAGE_ARCH = "${MACHINE_ARCH}",
without having to .bbappend every single recipe. It is indeed quite common
to have a .bbappend for qtbase, but not for the other packages...

thanks!

Re: making qt5 package machine specific

[Koen Kooi]

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

Nicolas Dechesne schreef op 21-11-13 09:33:
> hi,
> 
> we are building a product/distro with qt5 with support for various SoC.
> the way qt5 recipes are designed, it kind of forces the resulting
> packages to be  <machine> specific, not <arch> specific.
> 
> first each <machine> has a different provider for GL/GLES and it impacts 
> the RDEPENDS, on top of that we have machine specific patches in Qt5 in 
> each of our BSP layer, whether we like it or not, that's a reality that
> we cannot have the very same Qt5 config + source code for all platforms.
> 
> so we end up with many  <qt pkgs>-<arch> which are <machine> specific,
> not <arch>, and it messes up badly with sstate for example, especially
> when cleaning up the sstate (e.g. using sstate-cache-management -d).
> 
> so i have a couple of questions:
> 
> - are we doing something really wrong here? or are we getting issues
> that anyone would get when trying to have a OE based product with Qt5
> and multiple machines from the same <arch>?

You are getting issues that anyone with machine specific libs (e.g. GLES,
clutter, wayland) gets in a multimachine scenario :(

> - assuming this is a typical use case... i wish there was an easy 
> mechanism to 'mark' all Qt5 packages as PACKAGE_ARCH =
> "${MACHINE_ARCH}", without having to .bbappend every single recipe. It is
> indeed quite common to have a .bbappend for qtbase, but not for the other
> packages...

No idea on that, sorry.

regards,

Koen

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

iD4DBQFSjchFMkyGM64RGpERAkVvAJjvUEaYUnLHT9Y0akrxXC/fmj+NAJ4sFyr9
0JdnxMHb7/3P4JZoIEwmew==
=hr2K
-----END PGP SIGNATURE-----

Re: making qt5 package machine specific

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

On Thu, Nov 21, 2013 at 09:33:59AM +0100, Nicolas Dechesne wrote:
> hi,
> 
> we are building a product/distro with qt5 with support for various SoC. the
> way qt5 recipes are designed, it kind of forces the resulting packages to
> be  <machine> specific, not <arch> specific.
> 
> first each <machine> has a different provider for GL/GLES and it impacts
> the RDEPENDS, on top of that we have machine specific patches in Qt5 in
> each of our BSP layer, whether we like it or not, that's a reality that we
> cannot have the very same Qt5 config + source code for all platforms.
> 
> so we end up with many  <qt pkgs>-<arch> which are <machine> specific, not
> <arch>, and it messes up badly with sstate for example, especially when
> cleaning up the sstate (e.g. using sstate-cache-management -d).
> 
> so i have a couple of questions:
> 
>  - are we doing something really wrong here? or are we getting issues that
> anyone would get when trying to have a OE based product with Qt5 and
> multiple machines from the same <arch>?
> 
>  - assuming this is a typical use case... i wish there was an easy
> mechanism to 'mark' all Qt5 packages as PACKAGE_ARCH = "${MACHINE_ARCH}",
> without having to .bbappend every single recipe. It is indeed quite common
> to have a .bbappend for qtbase, but not for the other packages...

There are 2 ways and I'm using both in different scenarios (different
builds)

1) .inc file with
PACKAGE_ARCH_pn-qtbase = "${MACHINE_ARCH}"
PACKAGE_ARCH_pn-qtdeclarative = "${MACHINE_ARCH}"
...
for whole qt* stack (use sstate-diff-machines.sh script to see that you
get them all).

2) SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
# Depending on MACHINE_ARCH GL/GLES binaries (or mesa)
SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
    qtbase->other-gl-gles-provider \
    qtbase->mesa \
"

2) doesn't solve your MACHINE specific patches of course

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: making qt5 package machine specific

[Nicolas Dechesne]

On Thu, Nov 21, 2013 at 1:39 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> There are 2 ways and I'm using both in different scenarios (different
> builds)
>
> 1) .inc file with
> PACKAGE_ARCH_pn-qtbase = "${MACHINE_ARCH}"
> PACKAGE_ARCH_pn-qtdeclarative = "${MACHINE_ARCH}"
> ...
> for whole qt* stack (use sstate-diff-machines.sh script to see that you
> get them all).
>
> 2) SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
> # Depending on MACHINE_ARCH GL/GLES binaries (or mesa)
> SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
>     qtbase->other-gl-gles-provider \
>     qtbase->mesa \
> "
>
> 2) doesn't solve your MACHINE specific patches of course
>

thanks. how about getting something like this merged? i believe our
situation is going to be an issue for others as well, so perhaps it's nice
to build the infrastructure to make it simpler for people to use

=========

From c562d011f196b1ee8ceced76833dc80e48dd599f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
Date: Thu, 21 Nov 2013 13:48:45 +0000
Subject: [PATCH] qmake5_base.bbclass: allow to set the package arch globally
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Packages built using a (machine) specific qmake, will also be
machine specific.
Since it is not feasible to add PACKAGE_ARCH=... to each and every
recipe that is built using qmake, we introduce a new variable,
QMAKE_PACKAGE_ARCH, that can be set by the machine configuration as
needed.

We have to be careful though to only change the architecture of the
resulting packages if we're not compiling a 'native' package.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
 classes/qmake5_base.bbclass | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/classes/qmake5_base.bbclass b/classes/qmake5_base.bbclass
index 2db0fa3..e77dd73 100644
--- a/classes/qmake5_base.bbclass
+++ b/classes/qmake5_base.bbclass
@@ -1,3 +1,15 @@
+python __anonymous() {
+    barch = d.getVar("BUILD_ARCH", True) or ''
+    tarch = d.getVar("TARGET_ARCH", True) or ''
+    # do not do anything if we are building a native package
+    if barch == tarch:
+        True
+    else:
+        tarch = d.getVar("QMAKE_PACKAGE_ARCH", True) or ''
+        if tarch:
+            d.setVar("PACKAGE_ARCH", tarch)
+}
+
 # This is useful for target recipes to reference native mkspecs
 QMAKE_MKSPEC_PATH_NATIVE = "${STAGING_LIBDIR_NATIVE}/${QT_DIR_NAME}"
 QMAKE_MKSPEC_PATH_TARGET = "${STAGING_LIBDIR}/${QT_DIR_NAME}"
-- 
1.8.2

Re: making qt5 package machine specific

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3290 bytes --]

On Thu, Nov 21, 2013 at 04:11:00PM +0100, Nicolas Dechesne wrote:
> On Thu, Nov 21, 2013 at 1:39 PM, Martin Jansa <martin.jansa@gmail.com>wrote:
> 
> > There are 2 ways and I'm using both in different scenarios (different
> > builds)
> >
> > 1) .inc file with
> > PACKAGE_ARCH_pn-qtbase = "${MACHINE_ARCH}"
> > PACKAGE_ARCH_pn-qtdeclarative = "${MACHINE_ARCH}"
> > ...
> > for whole qt* stack (use sstate-diff-machines.sh script to see that you
> > get them all).
> >
> > 2) SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
> > # Depending on MACHINE_ARCH GL/GLES binaries (or mesa)
> > SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
> >     qtbase->other-gl-gles-provider \
> >     qtbase->mesa \
> > "
> >
> > 2) doesn't solve your MACHINE specific patches of course
> >
> 
> thanks. how about getting something like this merged? i believe our
> situation is going to be an issue for others as well, so perhaps it's nice
> to build the infrastructure to make it simpler for people to use

Looks useful, would you mind sending it with send-email so that it
correctly shows up in patchwork (now it breaks author and commit
message).

I'll let other reviewers some time to comment, but can merge it later.

> 
> =========
> 
> From c562d011f196b1ee8ceced76833dc80e48dd599f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
> Date: Thu, 21 Nov 2013 13:48:45 +0000
> Subject: [PATCH] qmake5_base.bbclass: allow to set the package arch globally
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Packages built using a (machine) specific qmake, will also be
> machine specific.
> Since it is not feasible to add PACKAGE_ARCH=... to each and every
> recipe that is built using qmake, we introduce a new variable,
> QMAKE_PACKAGE_ARCH, that can be set by the machine configuration as
> needed.
> 
> We have to be careful though to only change the architecture of the
> resulting packages if we're not compiling a 'native' package.
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
>  classes/qmake5_base.bbclass | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/classes/qmake5_base.bbclass b/classes/qmake5_base.bbclass
> index 2db0fa3..e77dd73 100644
> --- a/classes/qmake5_base.bbclass
> +++ b/classes/qmake5_base.bbclass
> @@ -1,3 +1,15 @@
> +python __anonymous() {
> +    barch = d.getVar("BUILD_ARCH", True) or ''
> +    tarch = d.getVar("TARGET_ARCH", True) or ''
> +    # do not do anything if we are building a native package
> +    if barch == tarch:
> +        True
> +    else:
> +        tarch = d.getVar("QMAKE_PACKAGE_ARCH", True) or ''
> +        if tarch:
> +            d.setVar("PACKAGE_ARCH", tarch)
> +}
> +
>  # This is useful for target recipes to reference native mkspecs
>  QMAKE_MKSPEC_PATH_NATIVE = "${STAGING_LIBDIR_NATIVE}/${QT_DIR_NAME}"
>  QMAKE_MKSPEC_PATH_TARGET = "${STAGING_LIBDIR}/${QT_DIR_NAME}"
> -- 
> 1.8.2
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: making qt5 package machine specific

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

On Thu, Nov 21, 2013 at 04:11:00PM +0100, Nicolas Dechesne wrote:
> On Thu, Nov 21, 2013 at 1:39 PM, Martin Jansa <martin.jansa@gmail.com>wrote:
> 
> > There are 2 ways and I'm using both in different scenarios (different
> > builds)
> >
> > 1) .inc file with
> > PACKAGE_ARCH_pn-qtbase = "${MACHINE_ARCH}"
> > PACKAGE_ARCH_pn-qtdeclarative = "${MACHINE_ARCH}"
> > ...
> > for whole qt* stack (use sstate-diff-machines.sh script to see that you
> > get them all).
> >
> > 2) SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS
> > # Depending on MACHINE_ARCH GL/GLES binaries (or mesa)
> > SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\
> >     qtbase->other-gl-gles-provider \
> >     qtbase->mesa \
> > "
> >
> > 2) doesn't solve your MACHINE specific patches of course
> >
> 
> thanks. how about getting something like this merged? i believe our
> situation is going to be an issue for others as well, so perhaps it's nice
> to build the infrastructure to make it simpler for people to use
> 
> =========
> 
> From c562d011f196b1ee8ceced76833dc80e48dd599f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
> Date: Thu, 21 Nov 2013 13:48:45 +0000
> Subject: [PATCH] qmake5_base.bbclass: allow to set the package arch globally
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Packages built using a (machine) specific qmake, will also be
> machine specific.
> Since it is not feasible to add PACKAGE_ARCH=... to each and every
> recipe that is built using qmake, we introduce a new variable,
> QMAKE_PACKAGE_ARCH, that can be set by the machine configuration as
> needed.
> 
> We have to be careful though to only change the architecture of the
> resulting packages if we're not compiling a 'native' package.

Ah one more comment.

qmake5_base.bbclass doesn't look like best place for it.

I guess you have only target qtbase being MACHINE_ARCH, right?

qmake5_base.bbclass can be inherited by many packages which are
TUNE_PKGARCH and don't use (depend) on target qtbase at all, so
QMAKE_PACKAGE_ARCH would be used in more recipes then where it's really
needed.

Cheers,

> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
>  classes/qmake5_base.bbclass | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/classes/qmake5_base.bbclass b/classes/qmake5_base.bbclass
> index 2db0fa3..e77dd73 100644
> --- a/classes/qmake5_base.bbclass
> +++ b/classes/qmake5_base.bbclass
> @@ -1,3 +1,15 @@
> +python __anonymous() {
> +    barch = d.getVar("BUILD_ARCH", True) or ''
> +    tarch = d.getVar("TARGET_ARCH", True) or ''
> +    # do not do anything if we are building a native package
> +    if barch == tarch:
> +        True
> +    else:
> +        tarch = d.getVar("QMAKE_PACKAGE_ARCH", True) or ''
> +        if tarch:
> +            d.setVar("PACKAGE_ARCH", tarch)
> +}
> +
>  # This is useful for target recipes to reference native mkspecs
>  QMAKE_MKSPEC_PATH_NATIVE = "${STAGING_LIBDIR_NATIVE}/${QT_DIR_NAME}"
>  QMAKE_MKSPEC_PATH_TARGET = "${STAGING_LIBDIR}/${QT_DIR_NAME}"
> -- 
> 1.8.2
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: making qt5 package machine specific

[André Draszik]

Hi Martin,

On Thu, 2013-11-21 at 18:30 +0100, Martin Jansa wrote:
> Ah one more comment.
> 
> qmake5_base.bbclass doesn't look like best place for it.
> 
> I guess you have only target qtbase being MACHINE_ARCH, right?

Everything that was built using the previously configured qtbase, e.g.
qtwebkit - see below.

> qmake5_base.bbclass can be inherited by many packages which are
> TUNE_PKGARCH and don't use (depend) on target qtbase at all, so
> QMAKE_PACKAGE_ARCH would be used in more recipes then where it's really
> needed.

I don't know enough about qmake, but my thinking is that qmake will
store the (qtbase) configure options somewhere (from the time when you
configure qtbase for the target), i.e. qmake during the qtwebkit build
has access to the configuration from the time qtbase was configured.
Hence the idea is to make all (target) packages that use (inherit)
qmake5 to use the same PACKAGE_ARCH override.

Does it work differently?


Cheers,
Andre'

Re: making qt5 package machine specific

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Fri, Nov 22, 2013 at 08:40:48AM +0000, André Draszik wrote:
> Hi Martin,
> 
> On Thu, 2013-11-21 at 18:30 +0100, Martin Jansa wrote:
> > Ah one more comment.
> > 
> > qmake5_base.bbclass doesn't look like best place for it.
> > 
> > I guess you have only target qtbase being MACHINE_ARCH, right?
> 
> Everything that was built using the previously configured qtbase, e.g.
> qtwebkit - see below.
> 
> > qmake5_base.bbclass can be inherited by many packages which are
> > TUNE_PKGARCH and don't use (depend) on target qtbase at all, so
> > QMAKE_PACKAGE_ARCH would be used in more recipes then where it's really
> > needed.
> 
> I don't know enough about qmake, but my thinking is that qmake will
> store the (qtbase) configure options somewhere (from the time when you
> configure qtbase for the target), i.e. qmake during the qtwebkit build
> has access to the configuration from the time qtbase was configured.
> Hence the idea is to make all (target) packages that use (inherit)
> qmake5 to use the same PACKAGE_ARCH override.

You can have recipes which use only qtbase-native and qmake only as
build tool and don't use target qtbase at all.

Such recipes inherit qmake5_base to setup paths etc and shouldn't became
MACHINE_ARCH just because target qtbase (which they don't use at all) is.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: making qt5 package machine specific

[André Draszik]

Thanks Martin!

On Fri, 2013-11-22 at 11:51 +0100, Martin Jansa wrote:
> You can have recipes which use only qtbase-native and qmake only as
> build tool and don't use target qtbase at all.
> 
> Such recipes inherit qmake5_base to setup paths etc and shouldn't became
> MACHINE_ARCH just because target qtbase (which they don't use at all) is.

OK.

Would it be better / ok to move my patch into qt5.inc then?

My only (maybe unjustified) concern with this is: What defines if some
source code uses / can see configuration options from qtbase configure
time when invoking qmake? Purely that projects own build system? I can't
see anything in meta-qt5 that could affect this, unless I'm missing
something.

In other words, could a recipe build sources that depend on the Qt
configuration, without including qt5.inc?


Cheers,
Andre'

Re: making qt5 package machine specific

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Fri, Nov 22, 2013 at 12:12:49PM +0000, André Draszik wrote:
> Thanks Martin!
> 
> On Fri, 2013-11-22 at 11:51 +0100, Martin Jansa wrote:
> > You can have recipes which use only qtbase-native and qmake only as
> > build tool and don't use target qtbase at all.
> > 
> > Such recipes inherit qmake5_base to setup paths etc and shouldn't became
> > MACHINE_ARCH just because target qtbase (which they don't use at all) is.
> 
> OK.
> 
> Would it be better / ok to move my patch into qt5.inc then?
> 
> My only (maybe unjustified) concern with this is: What defines if some
> source code uses / can see configuration options from qtbase configure
> time when invoking qmake? Purely that projects own build system? I can't
> see anything in meta-qt5 that could affect this, unless I'm missing
> something.

You can add it to separate .bbclass and inherit it from qt5.inc

> In other words, could a recipe build sources that depend on the Qt
> configuration, without including qt5.inc?

Yes any recipe which inherits qmake5 and also has qtbase added in
DEPENDS should inherit this class if it wants PACKAGE_ARCH to be
automatically adjusted.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[meta-qt5][PATCH] qt5.inc: allow to set the package arch globally

[André Draszik]

If Qt5 (qtbase) is machine specific, then all packages depending
on qtbase will also be machine specific, because the (initial)
qtbase configuration becomes part of Qt5/qmake, thus affecting
builds of packages built against this specific version of qtbase.

Since it is not feasible to add PACKAGE_ARCH=... to each and every
recipe that is built using qmake and depends on Qt5, we introduce
a new variable, QT_PACKAGES_ARCH, that can be set by the machine
configuration as needed.

We have to be careful though to only change the architecture of the
resulting packages if we're not compiling a 'native' package.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
 recipes-qt/qt5/qt5.inc | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc
index 7669efc..8d8438f 100644
--- a/recipes-qt/qt5/qt5.inc
+++ b/recipes-qt/qt5/qt5.inc
@@ -20,6 +20,18 @@ OE_QMAKE_PATH_SETTINGS = "${OE_QMAKE_PATH_QT_SETTINGS}"
 OE_QMAKE_PATH_EXAMPLES = "${OE_QMAKE_PATH_QT_EXAMPLES}"
 OE_QMAKE_PATH_TESTS = "${OE_QMAKE_PATH_QT_TESTS}"
 
+# If Qt5 (qtbase) is machine specific, then everything will be,
+# because the (initial) qtbase configuration becomes part of Qt5/qmake
+python __anonymous() {
+    barch = d.getVar("BUILD_ARCH", True) or ''
+    tarch = d.getVar("TARGET_ARCH", True) or ''
+    # do not do anything if we are building a native package
+    if barch != tarch:
+        tarch = d.getVar("QT_PACKAGES_ARCH", True) or ''
+        if tarch:
+            d.setVar("PACKAGE_ARCH", tarch)
+}
+
 PACKAGES =. "${PN}-qmlplugins-dbg ${PN}-tools-dbg ${PN}-plugins-dbg ${PN}-qmlplugins ${PN}-tools ${PN}-plugins ${PN}-mkspecs ${PN}-examples-dev ${PN}-examples-staticdev ${PN}-examples-dbg ${PN}-examples "
 
 # extra -dbg packages
-- 
1.8.1.2

[meta-qt5][PATCH] qt5.inc: allow to set the package arch globally

[Andre Draszik]

From: André Draszik <andre.draszik@linaro.org>

If Qt5 (qtbase) is machine specific, then all packages depending
on qtbase will also be machine specific, because the (initial)
qtbase configuration becomes part of Qt5/qmake, thus affecting
builds of packages built against this specific version of qtbase.

Since it is not feasible to add PACKAGE_ARCH=... to each and every
recipe that is built using qmake and depends on Qt5, we introduce
a new variable, QT_PACKAGES_ARCH, that can be set by the machine
configuration as needed.

We have to be careful though to only change the architecture of the
resulting packages if we're not compiling a 'native' package.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
 recipes-qt/qt5/qt5.inc | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc
index 7669efc..8d8438f 100644
--- a/recipes-qt/qt5/qt5.inc
+++ b/recipes-qt/qt5/qt5.inc
@@ -20,6 +20,18 @@ OE_QMAKE_PATH_SETTINGS = "${OE_QMAKE_PATH_QT_SETTINGS}"
 OE_QMAKE_PATH_EXAMPLES = "${OE_QMAKE_PATH_QT_EXAMPLES}"
 OE_QMAKE_PATH_TESTS = "${OE_QMAKE_PATH_QT_TESTS}"
 
+# If Qt5 (qtbase) is machine specific, then everything will be,
+# because the (initial) qtbase configuration becomes part of Qt5/qmake
+python __anonymous() {
+    barch = d.getVar("BUILD_ARCH", True) or ''
+    tarch = d.getVar("TARGET_ARCH", True) or ''
+    # do not do anything if we are building a native package
+    if barch != tarch:
+        tarch = d.getVar("QT_PACKAGES_ARCH", True) or ''
+        if tarch:
+            d.setVar("PACKAGE_ARCH", tarch)
+}
+
 PACKAGES =. "${PN}-qmlplugins-dbg ${PN}-tools-dbg ${PN}-plugins-dbg ${PN}-qmlplugins ${PN}-tools ${PN}-plugins ${PN}-mkspecs ${PN}-examples-dev ${PN}-examples-staticdev ${PN}-examples-dbg ${PN}-examples "
 
 # extra -dbg packages
-- 
1.8.1.2

Re: making qt5 package machine specific

[Otavio Salvador]

On Thu, Nov 21, 2013 at 6:33 AM, Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:
> so i have a couple of questions:
>
>  - are we doing something really wrong here? or are we getting issues that
> anyone would get when trying to have a OE based product with Qt5 and
> multiple machines from the same <arch>?
>
>  - assuming this is a typical use case... i wish there was an easy
> mechanism to 'mark' all Qt5 packages as PACKAGE_ARCH = "${MACHINE_ARCH}",
> without having to .bbappend every single recipe. It is indeed quite common
> to have a .bbappend for qtbase, but not for the other packages...

We have a similar case in meta-fsl where we have several packages
which are machine specific and SoC specific. We solved this using a
class that 'changes' the package-arch using the depends.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/fsl-dynamic-packagearch.bbclass

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750