[yocto] sstate black hole?
Paul Eggleton
paul.eggleton at linux.intel.com
Tue Jun 16 05:36:40 PDT 2015
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
More information about the yocto
mailing list