multilib_global.bbclass: PREFERRED_PROVIDERS for multilibs
authorPeter Seebach <peter.seebach@windriver.com>
Thu, 14 Aug 2014 18:03:36 +0000 (13:03 -0500)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Fri, 15 Aug 2014 17:21:50 +0000 (18:21 +0100)
commitc4b95bb5854bd07cae961ddc4a9a4e866c7512d4
treeb2d6c4352487b8fef688fb6031c463a2d0a49fe7
parente398d49465d20b17becc871232aba0508e570f4b
multilib_global.bbclass: PREFERRED_PROVIDERS for multilibs

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>
meta/classes/base.bbclass
meta/classes/multilib_global.bbclass