From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <pb@pbcl.net>, openembedded-core@lists.openembedded.org
Subject: Re: RSS difficulties
Date: Fri, 03 Feb 2017 11:20:07 +0000 [thread overview]
Message-ID: <1486120807.14144.68.camel@linuxfoundation.org> (raw)
In-Reply-To: <1486120259.13882.26.camel@pbcl.net>
On Fri, 2017-02-03 at 11:10 +0000, Phil Blundell wrote:
> I'm having a few problems adapting our build setup to work with
> recipe specific sysroots. More specifically, I am finding it
> difficult to get the correct set of components installed into the
> recipe-sysroot in all cases. In some cases I am getting too much
> (which causes build failures if oe attempts to stage two things that
> install the same file) and in other cases I am not getting enough.
>
> Could somebody explain, ideally using only small words, how the set
> of things to populate in the recipe-sysroot is determined? I assume
> it is based on the task dependency graph somehow but I'm not quite
> sure which relationships I ought to be looking at.
It comes down to what setscene_depvalid() in sstate.bbclass returns. If
that returns False a given dependency is installed, it if returns True,
it is skipped and not installed.
Reading that function should give some clues as to the logic it
applies. It operates not on a full task graph but on version collapsed
only to sstate tasks.
The logic should mirror what would get installed from sstate if that
sstate were available, hence the logic is somewhat tested and not just
new for RSS. That doesn't mean its right in all cases though!
If that doesn't help, perhaps some specific examples of what you think
should be being installed and isn't or things which are being installed
and shouldn't might help.
Cheers,
Richard
next prev parent reply other threads:[~2017-02-03 11:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 11:10 RSS difficulties Phil Blundell
2017-02-03 11:20 ` Richard Purdie [this message]
2017-02-03 12:29 ` Phil Blundell
2017-02-06 13:42 ` Phil Blundell
2017-02-06 14:27 ` Richard Purdie
2017-02-06 14:44 ` Phil Blundell
2017-02-06 16:30 ` Phil Blundell
2017-02-06 16:55 ` Phil Blundell
2017-02-06 17:05 ` Burton, Ross
2017-02-06 20:54 ` Khem Raj
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=1486120807.14144.68.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=pb@pbcl.net \
/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