multilib: Fix an OVERRIDES expansion order issue

Submitted by Richard Purdie on Feb. 13, 2013, 12:21 a.m.

Details

Message ID 1360714913.11225.24.camel@ted
State New
Headers show

Commit Message

Richard Purdie Feb. 13, 2013, 12:21 a.m.
There were problems where a SRC_URI with:

SRC_URI_append_powerpc = " xxx"
SRC_URI_append_powerpc64 = " xxx2"

would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.

The issue is that OVERRIDES has virtclass-multilib-xxxx added to it,
this eventually changed DEFAULTTUNE which then changes
TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
twice since once you apply an override, it doesn't get undone.

Expanding DEFAULTTUNE to the correct value in advance avoids the issue
and means only the correct overrides get applied.

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

Patch hide | download patch | download mbox

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 5454b4c..d52f721 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -51,6 +51,11 @@  python multilib_virtclass_handler () {
     e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHL
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
+
+    # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
+    newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant)
+    if newtune:
+        e.data.setVar("DEFAULTTUNE", newtune)
 }
 
 addhandler multilib_virtclass_handler

Comments

Mark Hatle Feb. 13, 2013, 12:27 a.m.
On 2/12/13 6:21 PM, Richard Purdie wrote:

Please add:

[ YOCTO #3874 ]

to the commit message.  (The problem is complex enough, that the bugzilla entry 
is helpful in understanding why this is needed.)


> There were problems where a SRC_URI with:
>
> SRC_URI_append_powerpc = " xxx"
> SRC_URI_append_powerpc64 = " xxx2"
>
> would end up with *both* xxx and xxx2 being added when using a multilib
> which is clearly incorrect and undesirable.
>
> The issue is that OVERRIDES has virtclass-multilib-xxxx added to it,
> this eventually changed DEFAULTTUNE which then changes
> TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
> re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
> twice since once you apply an override, it doesn't get undone.
>
> Expanding DEFAULTTUNE to the correct value in advance avoids the issue
> and means only the correct overrides get applied.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 5454b4c..d52f721 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -51,6 +51,11 @@ python multilib_virtclass_handler () {
>       e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
>       e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHL
>       e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
> +
> +    # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
> +    newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant)
> +    if newtune:
> +        e.data.setVar("DEFAULTTUNE", newtune)
>   }
>
>   addhandler multilib_virtclass_handler
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Peter Seebach Feb. 13, 2013, 3:33 a.m.
On Wed, 13 Feb 2013 00:21:53 +0000
Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> +    # DEFAULTTUNE can change TARGET_ARCH override so expand this now
> before update_data
> +    newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" +
> variant)

I was going to ask whether this wants a ", True", but it occurs to me
that I think it actually doesn't.

At which point I feel I should ask: Should there be an explicit
", False" so it doesn't get corrected in a later patch?

-s