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 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto