Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: DEPENDS tranlation with BBCLASSEXTEND
Date: Mon, 28 Mar 2011 13:48:33 +0100	[thread overview]
Message-ID: <1301316513.3018.192.camel@rex> (raw)
In-Reply-To: <AANLkTi=NeEXCqdyiQWaxA=aU96-Osuj+gE-zGRwkPH6-@mail.gmail.com>

On Sun, 2011-03-27 at 16:03 -0700, Chris Larson wrote:
> On Sun, Mar 27, 2011 at 1:08 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > I observed that if I have
> > DEPENDS = "a b" in recipe.bb which has BBCLASSEXTEND = "native"
> > then dependecies for recipe-native shows a-native b-native so far so
> > good
> >
> > Now if I want to add a dependency which only is needed for native recipe
> > I do
> >
> > DEPENDS_virtclass-native += "c-native"
> >
> > what this does is it will ignore a-native and b-native dependencies and
> > only adds "c-native" to depends of native recipe
> >
> > DEPENDS_virtclass-native_append = " c-native"
> >
> > This does what I wanted i.e. have deps on a-native b-native c-native
> >
> > I think behavior of += or _append should be similar. Is my understanding
> > correct ?
> 
> They've never been the same.  += is immediate, _append is delayed.  If
> a class, say, native.bbclass, defines the variable with ?=, and you
> used += before the inherit, then it will have a value, and the ?=
> won't assign.  I assume native.bbclass does it this way today so you
> can override the automatic behavior by defining the variable yourself,
> but I'll let Richard speak to that decision.

Thats the quick summary, yes. The DEPENDS variable is manipulated in
several different ways by the core and by .bb files and to coexist with
that, native.bbclass needs to play more games of its own. I recently
commented on that in another thread on this list.

I don't like the current situation, I'd like to simplify it and am open
to proposals on how we could do that as its too complicated at the
moment.

I would add that it does work though and the current situation using
BBCLASSEXTEND is a lot better than having many native .bb files IMO and
moves use closer to where we'd like to be.

Cheers,

Richard




  reply	other threads:[~2011-03-28 12:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-27 20:08 DEPENDS tranlation with BBCLASSEXTEND Khem Raj
2011-03-27 23:03 ` Chris Larson
2011-03-28 12:48   ` Richard Purdie [this message]
2011-03-28 19:03   ` Tom Rini
2011-03-28 19:48     ` Khem Raj
2011-03-28 20:06       ` Tom Rini
2011-03-28 20:11         ` Khem Raj
2011-03-28 20:24           ` Tom Rini

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=1301316513.3018.192.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /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