public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Randy MacLeod <randy.macleod@windriver.com>,
	Chen Qi <Qi.Chen@windriver.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [V2][oe][master][PATCH] packagegroup-cross-canadian: repackage when multilibs gcc gdb binutils changes
Date: Mon, 04 Jan 2021 21:17:16 +0000	[thread overview]
Message-ID: <e51444968f2ea90d3fa1aa53bad47c5668234b1a.camel@linuxfoundation.org> (raw)
In-Reply-To: <093bfa8a-ea5d-8cd2-997f-869b3674d4ca@windriver.com>

On Mon, 2021-01-04 at 16:00 -0500, Randy MacLeod wrote:
> On 2020-12-24 2:03 a.m., Chen Qi wrote:
> > ping
> 
> Ping v2.
> 
> Is there a problem with this solution or
> do you think we shouldn't handle the use case for some reason?
> 
> ../Randy
> > 
> > On 12/08/2020 09:58 AM, Jiping Ma wrote:
> > > 1. Build SDK without "MULTILIBS = """ in local.conf.
> > > 2. Build SDK again with "MULTILIBS = """ in local.conf, build
> > > will fail with the error info.
> > > Error:
> > >   Problem: conflicting requests
> > >    - nothing provides binutils-cross-canadian-arm needed by
> > > packagegroup-cross-canadian-nxp-ls1028-1.0-r0.x86_64_nativesdk
> > >    - ......
> > > diff --git a/meta/recipes-core/packagegroups/packagegroup-cross-
> > > canadian.bb b/meta/recipes-core/packagegroups/packagegroup-cross-
> > > canadian.bb
> > > index 3b430c0814..b6b3e5235f 100644
> > > --- a/meta/recipes-core/packagegroups/packagegroup-cross-
> > > canadian.bb
> > > +++ b/meta/recipes-core/packagegroups/packagegroup-cross-
> > > canadian.bb
> > > @@ -17,8 +17,13 @@ RDEPENDS_${PN} = "\
> > >       meta-environment-${MACHINE} \
> > >       "
> > >   
> > > -# When TUNE_ARCH changes but MACHINE does not (for example when
> > > a machine definition is updated),
> > > -# cross-canadian.bbclass prevents variable dependency
> > > propagation to TRANSLATED_TARGET_ARCH
> > > -# This will result in erroneous reuse of previous sstate
> > > packages. The following line
> > > -# establishes a direct dependency instead.
> > > -do_package[vardeps] += "TUNE_ARCH"
> > > +# When TUNE_ARCH, GCC, GDB, BINUTILS changes but MACHINE does
> > > not (for example when a machine
> > > +# definition is updated), cross-canadian.bbclass prevents
> > > variable dependency propagation to
> > > +# TRANSLATED_TARGET_ARCH This will result in erroneous reuse of
> > > previous sstate packages. The
> > > +# following line establishes a direct dependency instead.
> > > +do_package[vardeps] += "\
> > > +    ${@all_multilib_tune_values(d, 'BINUTILS')} \
> > > +    ${@all_multilib_tune_values(d, 'GDB')} \
> > > +    ${@all_multilib_tune_values(d, 'GCC')} \
> > > +    TUNE_ARCH \
> > > +    "

I keep putting off reviewing this as its wrong in several different
ways and its hard to explain. In particular:

a) vardeps takes names of variables yet all_multilib_tune_values()
returns values, not variable names. This alone makes it incorrect.

b) BINUTILS, GCC and GDB are artificial constructs which change with
TRANSLATED_TARGET_ARCH only so listing three values here is 
suboptimal, we just need to worry about TRANSLATED_TARGET_ARCH.

So really you want a way to say "depend on all the multilib versions of
TUNE_ARCH" but there is no way to express such a thing as a list of
variables.

You could put ${@all_multilib_tune_values(d, 'TRANSLATED_TARGET_ARCH')}
replacing TUNE_ARCH and it would probably work just as well as the
above but is also technically incorrect due to a).

I don't know how to fix this properly, except perhaps constructing an
artifical variable which does contain the expanded values of
TRANSLATED_TARGET_ARCH as vardepvalues?

Cheers,

Richard


      reply	other threads:[~2021-01-04 21:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08  1:58 [V2][oe][master][PATCH] packagegroup-cross-canadian: repackage when multilibs gcc gdb binutils changes Jiping Ma
2020-12-24  7:03 ` [OE-core] " Chen Qi
2021-01-04 21:00   ` Randy MacLeod
2021-01-04 21:17     ` Richard Purdie [this message]

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=e51444968f2ea90d3fa1aa53bad47c5668234b1a.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Qi.Chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=randy.macleod@windriver.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