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. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
