[yocto] sstate black hole?

[Gary Thomas]

On 2015-06-15 13:33, Gary Thomas wrote:
> On 2015-06-15 11:46, Martin Jansa wrote:
>> On Mon, Jun 15, 2015 at 11:41:47AM -0600, Gary Thomas wrote:
>>> On 2015-06-15 08:21, Martin Jansa wrote:
>>>> On Mon, Jun 15, 2015 at 07:35:20AM -0600, Gary Thomas wrote:
>>>>> I'm working with i.MX6 targets (meta-fsl-arm*).  For these
>>>>> targets, some packages are "special" in that they use i.MX6
>>>>> specific graphics support.  This ends up with an additional
>>>>> layer of stratification, so my tmp/work tree has:
>>>>>      all-amltd-linux
>>>>>      cortexa9hf-vfp-neon-amltd-linux-gnueabi
>>>>>      cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi
>>>>>      teton_p0382-amltd-linux-gnueabi
>>>>>      x86_64-amltd-linux-gnueabi
>>>>>      x86_64-linux
>>>>>
>>>>> The packages that are built in tmp/work/cortex* are architecture
>>>>> specific, not target specific, hence my question:
>>>>>
>>>>>      If I build for two i.MX6 targets, identical in every way
>>>>>      except for the ${MACHINE} name, if I use sstate to share
>>>>>      the builds from target A when building for target B, why
>>>>>      are the packages built in cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi
>>>>>      not shared by sstate?  I can see that they are present in
>>>>>      the sstate cache, but they are always rebuilt for target B.
>>>>>      I consider this incorrect behaviour as these are the same
>>>>>      architecture and so they should be sharable via sstate.
>>>>>
>>>>> Am I missing something here?  How can I determine why the
>>>>> package from target A (sstate cache) is not usable by target B?
>>>>
>>>> Use openembedded-core/scripts/sstate-diff-machines.sh to check if the
>>>> signatures of the recipes you expect to be re-used are the same.
>>>>
>>>
>>> How can I use this if the two targets have their own tmp/ tree?
>>
>> call it twice (once in each tmp tree) and compare resulting list.M files
>>
>
> Sadly, that script seems to destroy all of the .sigdata files which
> are needed to actually track down the culprit(s).
>

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)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------