From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: yocto@yoctoproject.org
Subject: Re: sstate black hole?
Date: Tue, 16 Jun 2015 13:36:40 +0100 [thread overview]
Message-ID: <1986608.cqN5gJUDst@peggleto-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <557FFED9.40205@mlbassoc.com>
On Tuesday 16 June 2015 04:47:53 Gary Thomas wrote:
> On 2015-06-16 02:37, Paul Eggleton wrote:
> > On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
> >> I followed this down to an i.MX6 specific package which is
> >>
> >> in DEPENDS:
> >> Variable PROVIDES value changed from
> >> '${PN} virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >>
> >> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> >> virtual/libgles2' to
> >>
> >> '${PN} virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >>
> >> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> >> virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
> >>
> >> Why aren't these considered the same (duplicate elements and/or order)
> >> should not matter for PROVIDES. Is there some way we could get bitbake
> >> to collapse this and remove the duplicates?
> >>
> >> I found that this happens in
> >> meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
> >>
> >> these lines:
> >> PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >>
> >> virtual/libopenvg virtual/libg2d"
> >> PROVIDES_append_mx6q = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >> PROVIDES_append_mx6dl = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >> PROVIDES_append_mx6sx = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >>
> >> Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
> >> and mx6dl, hence the duplication.
> >>
> >> Note: I removed the extra override (for testing) and found that
> >> now the packages built by target A can be shared via sstate with
> >> target B (at least the few I tested)
> >
> > I agree this would be nice, but for this to work we'd probably need to
> > introduce a typing system within bitbake so that it can understand that
> > this variable is a space-separated list. That is something we will
> > probably do at some point for a variety of reasons, but I don't know that
> > it's something we will get to soon.
>
> Is there some way to solve this in the recipe itself? I can see that
> it needs to make sure that those values are provided for each of the
> [sub]class of processor, but is there a way to write it so that they
> are only added once? Perhaps a little bit of Python magic?
Sure, you could use an anonymous python function with actual conditional
statements instead of overrides to set PROVIDES here.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2015-06-16 12:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 13:35 sstate black hole? Gary Thomas
2015-06-15 13:58 ` Nikolay Dimitrov
2015-06-15 14:21 ` Martin Jansa
2015-06-15 17:41 ` Gary Thomas
2015-06-15 17:46 ` Martin Jansa
2015-06-15 19:33 ` Gary Thomas
2015-06-16 0:19 ` Gary Thomas
2015-06-16 8:37 ` Paul Eggleton
2015-06-16 10:47 ` Gary Thomas
2015-06-16 12:36 ` Paul Eggleton [this message]
2015-06-16 13:21 ` Gary Thomas
2015-06-16 13:46 ` Paul Eggleton
-- strict thread matches above, loose matches on Subject: below --
2015-04-07 14:52 Gary Thomas
2015-04-07 15:27 ` Christopher Larson
2015-04-07 15:52 ` Gary Thomas
2015-04-07 16:19 ` Martin Jansa
2015-04-07 16:29 ` Gary Thomas
2015-04-07 16:33 ` Martin Jansa
2015-04-07 16:42 ` Gary Thomas
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=1986608.cqN5gJUDst@peggleto-mobl.ger.corp.intel.com \
--to=paul.eggleton@linux.intel.com \
--cc=gary@mlbassoc.com \
--cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.