Commit Graph

6 Commits

Author SHA1 Message Date
Richard Purdie 8e43f9a751 multilib: Abstract class extension code into classextend.py
(From OE-Core rev: 563828bad19a242bba9ce3db461bb5807037dfdf)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-05 12:36:29 +00:00
Dongxiao Xu 6f6863a258 multilib: remove the multilib handling to allarch
currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.

Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.

[YOCTO #1497]
[YOCTO #1498]

(From OE-Core rev: 64c0279e6b0d2325a326058476228360898550f3)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-28 14:58:53 +01:00
Mark Hatle a0530fc847 multilib_global.bbclass: Fix non-multilib package provides
In non-multilib packages, configured in a multilib configuration we
need to adjust the system provides and rprovides to include the
virtual multilib variant.

This resolves a problem introduced in the
329d864f9bbf94ad3aae8df43d63fe10e4237e4f commit.  Where "allarch"
packages were suddenly providing all variants of an object.

(From OE-Core rev: 66fa6b7e13fbcc5f75fb1b8aa3aedfbdbc148688)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-21 13:42:52 +01:00
Dongxiao Xu 50e184e0d9 multilib: Remove recipe from multilib.conf that inherits allarch
Recipes like update-rc.d and qemu-config inherit "allarch", thus we
shouldn't add multilib BBCLASSEXTEND for them in multilib.conf.

Besides, we need to add multilib packages as the RPROVIDER contents for
those recipes, in order to avoid the NoProvider error when parsing.

[YOCTO #1471]

(From OE-Core rev: 329d864f9bbf94ad3aae8df43d63fe10e4237e4f)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-13 17:08:13 +01:00
Dongxiao Xu 8d5c35bf99 multilib_global.bbclass: handle kernel-module-* for multilib
bitbake would report failed dependency of kernel-module-* when testing
multilib. kernel-module-* are recommended by some other recipes.

Do not extend name for kernel-module-* related packages.

[YOCTO #1456]

(From OE-Core rev: 30ac343888dc801614922045b374537c6c54f312)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-07 22:54:16 +01:00
Richard Purdie f9c3639238 multilib: Only build one kernel
For a given system we only want one kernel to be built. This change makes
the main kernel recipe provide all of the provides of the various enabled
multilibs hence allowing it to fulfil all the appropriate dependencies.

To make this work a global multilib class file needed to be created.

This patch also enables this multi provider functionality for "allarch"
packages.

[YOCTO #1361]

(From OE-Core rev: 2fd257f6c610624f05c8dd3fe1486364af04696f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-02 18:25:11 +01:00