Hi Gary, On 06/15/2015 04:35 PM, 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-linuxThe 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?
Are these packages (the ones that are getting rebuilt) depending on machine-specific headers (kernel)? Regards, Nikolay -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
