[yocto] [sstate question] How does SSTATE_CACHE work when shared?

[Patrick Ohly]

On Thu, 2017-05-11 at 13:22 +0000, Schmitt, Richard wrote:
> An example of our problem.  We are using a Xilinx BSP.  There is a
> recipe, device-tree-generation, that will deploy dtb files to the
> DEPLOY_IMAGE_DIR.  We are running into a case where other developers
> builds will fail when they run a task (in u-boot-xlnx) which depends
> on the dtb file being available in DEPLOY_IMAGE_DIR.  My assumption is
> that the shared state cache indicated that the dtb file did not need
> to be rebuilt because none of the dependencies changed, hence its
> signature had not changed.  But, it doesn’t actually exist in the
> users workspace (tmp/deploy/images).   
>  
> 
> Do I understand this correctly?

Yes.

>   Is there some step or configuration that I’m missing?  What is
> supposed to happen?  Is some magic supposed to copy a previous version
> of the dtb to the local deploy directory?

A "setscene" task should unpack the build result that was previously
placed into the sstate cache.

This sounds like a bug in the BSP and/or it hasn't been updated for the
version or OE-core that you use.

If this was part of a normal image recipe, my guess would be that the
BSP still copies directly to DEPLOY_DIR_IMAGE (thus bypassing the sstate
machinery) instead of to IMGDEPLOYDIR, and you are using a recent
OE-core. See "image: Deploy images to IMGDEPLOYDIR" (rev 6d969bacc718e2
in OE-core).

But for a separate recipe, it must be using deploy.bbclass incorrectly.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.