We need to be able to tell people if we WHITELIST a recipe
that contains an incompatible licese.

Example: If we set WHITELIST_GPL-3.0 ?= "foo", foo will end
up on an image even if GPL-3.0 is incompatible. This is the
correct behaviour but there is nothing telling people that it
is even happening.

(From OE-Core rev: c9da529943b2f563b7b0aeb43576c13dd3b6f932)

Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>

Without this changing just the SRCREV won't re-fetch unless you embed the SRCREV
into PV.

The downside here is that every hash changes, so this causes a full rebuild.

Signed-off-by: Ross Burton <ross.burton@intel.com>
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.

Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

If INCOMPATIBLE_LICENSE=GPL-3.0 but the recipe sets LICENSE=GPLv3, the current
code won't trigger because they're different strings.

Fix this by attempting to canonicalise every license name to a SPDX name, so
both names in this example become GPL-3.0.

[ YOCTO #5622 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Now that gcc-cross, gcc-crosssdk and others have expanded variables in
their names, the code that previous just applied to cross-canadian needs
expanding to cover the other cases. Improve the conditional and also
fix a bug where the multilib prefix wasn't being added into the generated
versions.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Unfortunately expandKeys() notices overlap between the SDK and TARGET
PREFERRED_PROVIDERS entries when we set things up for the SDK recipes.

To avoid this, delete one of the sets of keys to avoid supurious warnings.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Add in the TARGET_ARCH and SDK_ARCH suffixes from the gcc-cross changes.
The -intermediate toolchain parts were canned a while ago so drop them.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

There were two ConfigParsed event handlers in base.bbclass, this merges
them together for small efficiency wins.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>