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?



Paul Eggleton
Intel Open Source Technology Centre
yocto mailing list

Reply via email to