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.
(From OE-Core rev: 8de0c5d3bd01919e2bf0394f9c485936d6098cec)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code was pointless so cleanup, drop the unused event and the
filtering is no longer needed.
(From OE-Core rev: 4fd9e74035703b45a9e6e9143b1ec421e172200c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
newval is not defined in all cases. Set to None and check if it is set.
File
"/local/foo/builds/x86/layers/openembedded-core/meta/classes/multilib_global.bbclass",
line 90, in preferred_ml_updates(d=<bb.data_smart.DataSmart object at
0xf6fd528c>):
if not d.getVar(newname, False):
> d.setVar(newname, localdata.expand(newval))
# Avoid future variable key expansion
UnboundLocalError: local variable 'newval' referenced before assignment
(From OE-Core rev: 25ebd3bbc1f9f4b1b6147d98dd43690c3bf03ee7)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
multilib task signatures turned out to have issues since
SIGGEN_EXCLUDERECIPES_ABISAFE and SIGGEN_EXCLUDE_SAFE_RECIPE_DEP
did not have multilib mappings. This adds those mappings in which
in turn improves multilib task checksums to match the standard
non-mulitlib versions.
(From OE-Core rev: ea872b735c92a30d03cfa32953e060430e6f7f0b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our multilib cross toolchains have <ml_prefix> as a prefix however we
only have a single gcc-cross-canadian for each arch and it is not
prefixed even in the multilib case. We can have two versions of
gcc-cross-canadian, 32 and 64 bit.
This fixes the multilib PREFERRED_VERSION mapping code so that
no prefix is added to the preferred version and therefore the
right versions of gcc-cross-canadian are used.
(From OE-Core rev: c4b3540fc2b66730e021dd0b0c89b0fbe9dbf77a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This ensures that in cases where the preference value changes when the
multilib override is applied, we correctly expand it in that context.
For example, for `PREFERRED_PROVIDER_${TARGET_PREFIX}gcc
= "gcc-external-cross-${TARGET_ARCH}"`, when it sets the prefixed version of
this, we want TARGET_ARCH expanded with the multilib applied, otherwise the
arch suffix will be incorrect for that context.
We ran into this trying to use preferences in meta-sourcery along with
multilibs. We worked around it there via PNBLACKLIST, but this fix should
still go into the core.
(From OE-Core rev: 4d208ebacb3a5d189998ac9be6d1a454c45aa975)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the resulting RPROVIDES is empty, don't set it. This streamlines
pkgdata slightly removing empty values and avoids other errors which
confuse the datastore when the variable is best left unset.
(From OE-Core rev: fe10ea6bd6078828016d3954ad9b290f638d6dbb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in base.bbclass to spread PREFERRED_PROVIDERS values
to multilibs doesn't work for things which rely on TARGET_PREFIX,
such as virtual/${TARGET_PREFIX}gcc. This is because the expansion
of TARGET_PREFIX produces the wrong value if executed prior to
the assignment of TARGET_VENDOR_virtclass-multilib-libxx, which
will always happen since that assignment doesn't happen until recipe
parsing, but the PREFERRED_PROVIDERS expansion is happening
around ConfigParsed.
To solve this, we make a couple of changes. First, the creation
of the TARGET_VENDOR override values is moved into a new ConfigParsed
event handler in multilib_global. Second, the preferred_ml_updates()
function's code is moved into that function too. It seems safe to
assume that PREFERRED_PROVIDER values only need to be spread to
other multilibs when multilibs are in use.
I don't think this directly affects any use cases that don't involve
third-party or alternative toolchains.
(From OE-Core rev: 513f72274460e54fd35dda5ef70fa42ba2b284f8)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: bff73743280f9eafebe4591f7368ead91a4eb74d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some left over tab characters in the python functions. This
removes them and resolves python 3 errors.
(From OE-Core rev: fafeb381c48291fa65c634c01c244843c8d7fad3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- 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]
(From OE-Core rev: bc4da2573dfb59ea2fc4af359701818df20f7663)
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current multilib search path code for packagedata is flawed since it
doesn't correctly handle changes in the TARGET_VENDOR/TARGET_OS that
multilib may make. This patch enhances the code to correctly build the
search paths so multilib packagedata is found correctly.
(From OE-Core rev: f50c5d36b2da9b36d56d95a7d89404509a1a3e9b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
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>
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>
Richard Purdie
Joshua Lock
Jeremy Puhlman
Christopher Larson
Peter Seebach
Constantin Musca
Dongxiao Xu
Mark Hatle