[yocto] sstate black hole?

[Gary Thomas]

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).

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