[1/2] classes/multilib: ensure MLPREFIX is set for image recipes

Submitted by Paul Eggleton on Sept. 21, 2012, 4:40 p.m.

Details

Message ID 12e61841995abb0cd1a96b334edc982c80a7d47f.1348245594.git.paul.eggleton@linux.intel.com
State New
Headers show

Commit Message

Paul Eggleton Sept. 21, 2012, 4:40 p.m.
We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
the value of BPN) can derive the bare name from the multilib-extended
name for image recipes. BPN being set correctly avoids missing file
warnings during parse from the file checksum code for (unusual) images
that set SRC_URI, such as build-appliance-image.

First half of the fix for [YOCTO #3146].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/multilib.bbclass |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index b1a593e..25cf068 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -11,13 +11,17 @@  python multilib_virtclass_handler () {
     if bb.data.inherits_class('kernel', e.data) or bb.data.inherits_class('module-base', e.data):
         raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")
 
-    if bb.data.inherits_class('image', e.data):
-        e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
-        return
-
     if bb.data.inherits_class('native', e.data):
         raise bb.parse.SkipPackage("We can't extend native recipes")
 
+    # Set variables suitable for image recipes (as well as everything else)
+    e.data.setVar("MLPREFIX", variant + "-")
+    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
+
+    if bb.data.inherits_class('image', e.data):
+        # We've set all we need to set for images here
+        return
+
     save_var_name=e.data.getVar("MULTILIB_SAVE_VARNAME", True) or ""
     for name in save_var_name.split():
         val=e.data.getVar(name, True)
@@ -29,8 +33,6 @@  python multilib_virtclass_handler () {
  
     override = ":virtclass-multilib-" + variant
 
-    e.data.setVar("MLPREFIX", variant + "-")
-    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
     if e.data.getVar("TARGET_VENDOR_virtclass-multilib-" + variant, False) is None:
 	    e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant, e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)

Comments

Richard Purdie Sept. 22, 2012, 11:55 a.m.
On Fri, 2012-09-21 at 17:40 +0100, Paul Eggleton wrote:
> We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
> the value of BPN) can derive the bare name from the multilib-extended
> name for image recipes. BPN being set correctly avoids missing file
> warnings during parse from the file checksum code for (unusual) images
> that set SRC_URI, such as build-appliance-image.
> 
> First half of the fix for [YOCTO #3146].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  meta/classes/multilib.bbclass |   14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index b1a593e..25cf068 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -11,13 +11,17 @@ python multilib_virtclass_handler () {
>      if bb.data.inherits_class('kernel', e.data) or bb.data.inherits_class('module-base', e.data):
>          raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")
>  
> -    if bb.data.inherits_class('image', e.data):
> -        e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> -        return
> -
>      if bb.data.inherits_class('native', e.data):
>          raise bb.parse.SkipPackage("We can't extend native recipes")
>  
> +    # Set variables suitable for image recipes (as well as everything else)
> +    e.data.setVar("MLPREFIX", variant + "-")
> +    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> +
> +    if bb.data.inherits_class('image', e.data):
> +        # We've set all we need to set for images here
> +        return
> +
>      save_var_name=e.data.getVar("MULTILIB_SAVE_VARNAME", True) or ""
>      for name in save_var_name.split():
>          val=e.data.getVar(name, True)
> @@ -29,8 +33,6 @@ python multilib_virtclass_handler () {
>   
>      override = ":virtclass-multilib-" + variant
>  
> -    e.data.setVar("MLPREFIX", variant + "-")
> -    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
>      e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)
>      if e.data.getVar("TARGET_VENDOR_virtclass-multilib-" + variant, False) is None:
>  	    e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant, e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)


We can't do this due to MULTILIB_SAVE_VARNAME which may then get
influenced by the PN change. This is why the PN setting is duplicated,
we probably need to just duplicate the MLPREFIX line too. Ugly but such
is life :/

Cheers

Richard
Paul Eggleton Sept. 22, 2012, 11:58 a.m.
On Saturday 22 September 2012 12:55:53 Richard Purdie wrote:
> On Fri, 2012-09-21 at 17:40 +0100, Paul Eggleton wrote:
> > We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
> > the value of BPN) can derive the bare name from the multilib-extended
> > name for image recipes. BPN being set correctly avoids missing file
> > warnings during parse from the file checksum code for (unusual) images
> > that set SRC_URI, such as build-appliance-image.
> > 
> > First half of the fix for [YOCTO #3146].
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> > ---
> > 
> >  meta/classes/multilib.bbclass |   14 ++++++++------
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> > index b1a593e..25cf068 100644
> > --- a/meta/classes/multilib.bbclass
> > +++ b/meta/classes/multilib.bbclass
> > @@ -11,13 +11,17 @@ python multilib_virtclass_handler () {
> > 
> >      if bb.data.inherits_class('kernel', e.data) or 
bb.data.inherits_class('module-base', e.data):
> >          raise bb.parse.SkipPackage("We shouldn't have multilib variants
> >          for the kernel")> 
> > -    if bb.data.inherits_class('image', e.data):
> > -        e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> > -        return
> > -
> > 
> >      if bb.data.inherits_class('native', e.data):
> >          raise bb.parse.SkipPackage("We can't extend native recipes")
> > 
> > +    # Set variables suitable for image recipes (as well as everything
> > else) +    e.data.setVar("MLPREFIX", variant + "-")
> > +    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> > +
> > +    if bb.data.inherits_class('image', e.data):
> > +        # We've set all we need to set for images here
> > +        return
> > +
> > 
> >      save_var_name=e.data.getVar("MULTILIB_SAVE_VARNAME", True) or ""
> >      
> >      for name in save_var_name.split():
> >          val=e.data.getVar(name, True)
> > 
> > @@ -29,8 +33,6 @@ python multilib_virtclass_handler () {
> > 
> >      override = ":virtclass-multilib-" + variant
> > 
> > -    e.data.setVar("MLPREFIX", variant + "-")
> > -    e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
> > 
> >      e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant
> >      ,e.data.getVar("SHLIBSDIR", False) + "/" + variant)>      
> >      if e.data.getVar("TARGET_VENDOR_virtclass-multilib-" + variant, 
False) is None:
> >  	    e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant,
> >  	    e.data.getVar("TARGET_VENDOR", False) + "ml" + variant)
>
> We can't do this due to MULTILIB_SAVE_VARNAME which may then get
> influenced by the PN change. This is why the PN setting is duplicated,
> we probably need to just duplicate the MLPREFIX line too. Ugly but such
> is life :/

Oops. I'll send a v2 shortly.

Cheers,
Paul