On 2015-06-15 11:46, Martin Jansa wrote:
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
Sadly, that script seems to destroy all of the .sigdata files which
are needed to actually track down the culprit(s).
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
