openembedded-core.git/meta/lib/oe/classextend.py, branch uninative-1.4

lib/classextend: Fix determinism issue

2016-05-11T09:08:30+00:00

The ordering of dependency variables needs to be deterministic to avoid task checksums
changing. Use an OrderedDict to achieve this.

Signed-off-by: Richard Purdie

lib/oe/classextend: Fix nativesdk double name mapping

2015-07-29T21:53:23+00:00

Handle the case a name has already been extended in the nativesdk case
(avoids double name extensions which can happen with nativesdk-gcc).

Signed-off-by: Richard Purdie

classextend: Do not extend for that already have multilib prefix

2014-11-12T15:36:13+00:00

If a BSP supports two or more multilibs, for example:

    MULTILIBS = "multilib:lib32 multilib:lib64"

and a variable is already extended to include multilib variants,
for example in populate_sdk_base:

    commit 396371588c7fd2d691ca9c39cd02287e43cb665b
    Author: Richard Purdie 
    Date: Thu Jul 24 22:09:09 2014 +0100

    populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib variants

    Most people expect the toolchain from a multilib build to contain multilib
    components. This change makes that happen and is easy for users to override
    should they want something different.

    Signed-off-by: Richard Purdie 

The mapping clsextend.map_depends_variable("TOOLCHAIN_TARGET_TASK")
ends up with a wrong double extended package name like:

    lib32-lib64-packagegroup-core-standalone-sdk-target

This patch avoid such issues.

Signed-off-by: Jackie Huang 
Signed-off-by: Ross Burton

lib/oe/classextend: Avoid early expansion of PR values

2014-07-25T14:33:32+00:00

Variables like RDEPENDS can contain EXTENDPKGV which in turn uses AUTOPR
based values. This gets set during do_package execution so we want to
defer expansion until then. The only way we can do this in the RDEPENDS
(and friends) mapping code is to subsitute a dummy value, then change it
back again. Horrible but I can't see any other way.

This resolves multilib build failures with inconsistent PR values.

Signed-off-by: Richard Purdie

classextend: Fix crosssdk remapping for multilib

2014-06-01T13:28:35+00:00

Multilib builds only require one crosssdk toolchain. We therefore shouldn't
be remapping crosssdk names. This resolves build failures looking for
weird multilib crosssdk toolchains.

Signed-off-by: Richard Purdie

classes/lib/oe: Fix cross/crosssdk references

2014-05-11T11:26:36+00:00

With the renaming of the cross packages, its no longer possible to use
endswith("-cross") and similar to detect cross packages. Replace these
references with other techniques.

This resolves certain build from sstate failures which were due to the
system believing cross packages were target packages and therefore
dependency handling was altered.

Signed-off-by: Richard Purdie 
Signed-off-by: Saul Wold

lib/oe/classextend.py: avoid extending any kernel package

2013-04-05T16:35:04+00:00

For multilib and other uses of classextend, we don't want any
dependencies on kernel packages to be extended since there should only
be one kernel variant.

Fixes [YOCTO #2918] (where kernel-dev was being extended.)

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classextend.py: use explode_dep_versions2 in order to preserve versions too

2013-02-06T09:35:04+00:00

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

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

lib/oe/classextend: Ensure we don't extend expressions more than once

2012-11-06T08:29:03+00:00

We could end up with MLPREFIX being prepended to variables like
PACKAGE_DYNAMIC. This patch avoids the problem and unbreaks builds.

[YOCTO #3389]

Signed-off-by: Richard Purdie