From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] classes/multilib: ensure MLPREFIX is set for image recipes
Date: Sat, 22 Sep 2012 12:55:53 +0100 [thread overview]
Message-ID: <1348314953.10108.204.camel@ted> (raw)
In-Reply-To: <12e61841995abb0cd1a96b334edc982c80a7d47f.1348245594.git.paul.eggleton@linux.intel.com>
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
next prev parent reply other threads:[~2012-09-22 12:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 16:40 [PATCH 0/2] Fixes for warnings during parse with multilib Paul Eggleton
2012-09-21 16:40 ` [PATCH 1/2] classes/multilib: ensure MLPREFIX is set for image recipes Paul Eggleton
2012-09-22 11:55 ` Richard Purdie [this message]
2012-09-22 11:58 ` Paul Eggleton
2012-09-21 16:40 ` [PATCH 2/2] classes/multilib: prevent multilib extension of nativesdk recipes Paul Eggleton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1348314953.10108.204.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox