[yocto] sstate black hole?

[Paul Eggleton]

On Tuesday 16 June 2015 07:21:05 Gary Thomas wrote:
> On 2015-06-16 06:36, Paul Eggleton wrote:
> > 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.
> 
> Thanks.  I found a much simpler way - I replaced the previous version by:
>    EXTRA_PROVIDES = ""
>    EXTRA_PROVIDES_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> EXTRA_PROVIDES_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> EXTRA_PROVIDES_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d ${EXTRA_PROVIDES}"
> 
> If the additions were unique, i.e. _mx6q was somehow different from _mx6dl,
> I would have had to use the python function, but since they are all the same
> this simpler way works just fine.

Yep, that will work too - good job :)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre