openembedded-core.git/meta/classes/multilib.bbclass, branch dora

multilib: Ensure we map the SYSTEMD_PACKAGES variable

2014-01-26T06:08:15+00:00

If we don't do this, systemd.bbclase will complain to unable to find multilib
packages since PACKAGES is expand with mlprefix, but SYSTEMD_PACKAGES is not,
like in ntp.inc:

    $grep PACKAGES meta-oe/meta-networking/recipes-support/ntp/ntp.inc
    PACKAGES += "ntpdate sntp ${PN}-tickadj ${PN}-utils"
    SYSTEMD_PACKAGES = "${PN} ntpdate sntp"
    $

    $bitbake ntp
    ERROR: ntpdate does not appear in package list, please add it
    ERROR: sntp does not appear in package list, please add it
    $

(From OE-Core master rev: 84f1d3252c369dff06a517baa4fd7fe274782e40)

Signed-off-by: Roy Li 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific directory

2013-09-13T16:41:10+00:00

Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.

This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.

With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.

The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.

It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.

Signed-off-by: Richard Purdie

multilib.bbclass: Expand the WHITELISTs with multilib prefix

2013-08-30T17:06:26+00:00

fix the following failures:
ERROR: Nothing PROVIDES 'virtual/lib32-i586-pokymllib32-linux-compilerlibs'
ERROR: Nothing RPROVIDES 'lib32-update-alternatives-cworth'

Signed-off-by: Jackie Huang 
Signed-off-by: Saul Wold

classes/conf: Add eventmasks for event handlers

2013-06-14T11:55:22+00:00

Now that bitbake supports masking events for event handlers, lets use
this so event handlers are only called for events they care about. This
lets us simplify the code indentation a bit at least as well as mildly
improving the event handling performance.

Signed-off-by: Richard Purdie

multilib.bbclass: fix the PACKAGEFUNCS_append

2013-06-07T15:41:02+00:00

The PACKAGEFUNCS_append = "do_package_qa_multilib" lacks a "space",
which would cause unexpected errors.

[YOCTO #3190]
[YOCTO #4396]

Signed-off-by: Robert Yang 
Signed-off-by: Saul Wold

multilib: Ensure we map the USERADD_PACKAGES variable

2013-04-18T14:30:35+00:00

If we don't do this, multilib packages don't have any code
added to the postinstalls to handle user additions.

Signed-off-by: Richard Purdie

multilib: Fix an OVERRIDES expansion order issue

2013-02-14T10:05:10+00:00

There were problems where a SRC_URI with:

SRC_URI_append_powerpc = " xxx"
SRC_URI_append_powerpc64 = " xxx2"

would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.

The issue is that OVERRIDES has virtclass-multilib-xxxx added to it,
this eventually changed DEFAULTTUNE which then changes
TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
twice since once you apply an override, it doesn't get undone.

Expanding DEFAULTTUNE to the correct value in advance avoids the issue
and means only the correct overrides get applied.

[YOCTO #3874]

Signed-off-by: Richard Purdie

multilib.bbclass: save multilib variables before executing the gcc-cross-canadian statements

2013-02-11T22:49:07+00:00

Signed-off-by: Constantin Musca 
Signed-off-by: Richard Purdie

multilib: skip packages that provide virtual/kernel

2013-02-01T15:40:44+00:00

Rather than keying on recipes that inherit kernel.bbclass, we should
be checking for providers of virtual/kernel when skipping kernel
recipes in multlib builds.

Not all providers of virtual/kernel inherit kernel.bbclass (notably
linux-dummy), so checking on the provider is a more complete check.

We need to be sure to check for inheritance of module-base as well, this
allows for packages that provides modules to avoid the multilib renaming.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Mark Hatle 
Signed-off-by: Richard Purdie

multilib: fix allarch/kernel/module-base multilib issues

2012-12-31T09:42:48+00:00

- skip the non-packagegroup allarch recipes in multilib_virtclass_handler
- extend PROVIDES/RPROVIDES for allarch recipes which are not packagegroups
- use variants from MULTILIB_GLOBAL_VARIANTS (lib32 lib64 libx32) to create
additional pkgdata files for multilib allarch: ${pkgdatadir}/${variant}-${PN}
and ${pkgdatadir}/runtime/${variant}-${pkg}
- use variants from MULTILIB_VARIANTS to create additional pkgdata files
for multilib kernel/module-base recipes
- add a sanity check to determine if the current multilib is in
MULTILIB_GLOBAL_VARIANTS

[YOCTO #2918]
[YOCTO #3440]
[YOCTO #3565]
[YOCTO #3568]

Signed-off-by: Constantin Musca 
Signed-off-by: Saul Wold