[yocto] sstate black hole?
Gary Thomas
gary at mlbassoc.com
Tue Jun 16 06:21:05 PDT 2015
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.
Thanks for the pointers
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
More information about the yocto
mailing list