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

blacklist.bbclass: fix for multilib

2017-04-12T21:16:55+00:00

* Fixed:
  The netmap has been blacklisted in
  meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can
  be built (suppose it doesn't depend on another broken recipe netmap-modules, it
  is a little complicated, will talk below):
  $ bitbake lib32-netmap

  This is because of the old code masks on bb.event.ConfigParsed which can only
  handle global blacklist, netmap sets blacklist in the recipe, so it can't be
  handled, and lib32-netmap can be built. which was incorrect:
  blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed"

  Move multilib code into multilib.bbclass can fix the problem easily:
  $ bitbake lib32-netmap
    ERROR: Nothing PROVIDES 'lib32-netmap'
    ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: 

* Not fixed
  Another problem is netmap-modules has also been blacklisted in the recipe, and
  the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the
  code shows:
    # There should only be one kernel in multilib configs
    # We also skip multilib setup for module packages.
    provides = (e.data.getVar("PROVIDES") or "").split()
    if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data):
        raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")

  And netmap-modules provides lib32-netmap-modules which is handled in
  multilib_global.bbclass, so bitbake lib32-netmap-modules can't show
  the blacklist message:
  $ bitbake netmap-modules
  ERROR: Nothing PROVIDES 'netmap-modules'
  ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: 
  ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel

  $ bitbake lib32-netmap-modules
  ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches:
    netmap-modules
    netmap-modules
    lib32-fbset-modes

  Note the different messages between netmap-modules and lib32-netmap-modules.
  This is because multilib.bbclass doesn't handle the "module" recipe so
  there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't
  handle it.

  Note, there are two "netmap-modules" which needs to be fixed later.

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

classes: Drop now unneeded update_data calls

2017-02-15T17:29:41+00:00

Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.

Signed-off-by: Richard Purdie

meta/scripts: Various getVar/getVarFlag expansion parameter fixes

2017-01-06T11:46:14+00:00

There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:

d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')

which I've corrected (they happend to work by luck).

Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T08:30:03+00:00

getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock 
Signed-off-by: Ross Burton

base.bbclass: drop obsolete HOSTTOOLS_WHITELIST_GPL-3.0

2016-03-31T22:02:27+00:00

base.bbclass sets 'check_license' to False (and therefore skips
license checking completely) for native, nativesdk, etc recipes
(ie anything which could potentially be classed as "host tools"),
so supporting a dedicated whitelist of GPLv3 host tools is not
necessary.

Signed-off-by: Andre McCurdy 
Signed-off-by: Richard Purdie

mulitlib: Ensure SDKTARGETSYSROOT is set correctly

2015-09-26T16:57:44+00:00

When building something like lib32-core-image-minimal -c populate_sdk, we
expect one sysroot with both multilibs installed. We therefore
need a single SDKTARGETSYSROOT value which doesn't change when multilibs
are enabled.

This makes the image generation code match what the meta-environment
files set the SDK up to use.

Signed-off-by: Richard Purdie

multilib: Drop populate_sdk variable manipulation

2015-09-26T16:57:21+00:00

I believe this code dates from previous times when we didn't extend
the TOOLCHAIN_TARGET* variables to cover all multilibs. We now do
this so this code acutally breaks things by removing the non-multilib
variants.

By changing this, a multilib SDK now contains both sets of base libraries
which matches the tools we ship with it. If the user wishes to customise,
this also becomes easier.

Signed-off-by: Richard Purdie

multilib.bbclass: use package_qa_handle_error

2015-06-11T22:56:29+00:00

Use package_qa_handle_error to handle the QA issue.

Signed-off-by: Robert Yang

multilib: Tweak value of PN used for OVERRIDES

2015-05-03T10:39:48+00:00

Currently, PN is used in overrides which is expanded to have a MLPREFIX. This
means and pn- overrides without the prefix would be ignored which is not what
is usually expected.

We noticed huge problems using poky-lsb with multilib since the per recipe
overrides were not applied. This adds in handling for PN with and without
the prefix. This should unbreak world-lsb builds on the autobuilder.

Signed-off-by: Richard Purdie

multilib.bbclass/package_manager.py: fix -meta-toolchain build failure

2014-11-04T10:19:54+00:00

There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But for the build of lib32-
meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is
deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...
|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"
...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted
it at DataSmart.finalize
...
Author: Richard Purdie 
Date:   Tue May 31 23:52:50 2011 +0100

    bitbake/data_smart: Change overrides behaviour to remove
       expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_', assign it with the
value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib
-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_

[YOCTO #6842]

Signed-off-by: Hongxu Jia 
Signed-off-by: Ross Burton