[sstate question] How does SSTATE_CACHE work when shared?

[sstate question] How does SSTATE_CACHE work when shared?

[Schmitt, Richard]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

The writeup in section 4.3.3 of the Yocto reference manual is quite good but I'm still left with a question that I'm hoping someone can shed some light into.

We have the SSTATE_CACHE set up as a shared directory on a build machine.  This means that multiple developers with their own workspaces will all share the same SSTATE_CACHE.  What is not clear is how, or whether the build artifacts are actually shared between developers.

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?  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?  Is there something that was supposed invalidate the cache for the local user?  We can work around this by forcing the developer to execute a cleansstate on device-tree-generation but what is going wrong.

Thanks,
Rich

[-- Attachment #2: Type: text/html, Size: 3557 bytes --]

Re: [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.