On Thu, 01 Dec 2016 10:27:50 Gary Thomas wrote:
> I have a build machine where I build for lots of targets. On
> all of these targets (save a primary), I set the SSTATE_MIRROR
> to point to the sstate-cache of the primary target. I always build
> for the primary target first, then later the secondary ones.
> For the most part, the sstate mechanism works pretty well, but I
> see some anomalies. For example, why on the same host, built back
> to back, would a secondary build target (which uses the primary
> as it's SSTATE_MIRROR and that build is complete) need to rebuild
> from scratch such NATIVE packages as openssl? Note that these are
> native packages I'm asking about, so in my mind they should always
> be sharable.
> Any ideas? Is there something I can look at to investigate this?
bitbake-diffsigs is the basic tool to compare signatures when those have
changed. Find the siginfo / sigdata file for one of the early tasks that
executed and compare them to see what changed.
How are you setting SSTATE_MIRRORS in this scenario btw?
Intel Open Source Technology Centre
yocto mailing list