I'm using oe-core/scripts/sstate-diff-machines.sh script (which calls bitbake -S) to generate "snapshots" of sstate signatures for interesting builds (in our case daily official builds) and then every time I notice something unexpectedly being rebuilt, I can use the same script to create snapshot of my local build and then compare these 2.
Once it helps you find which recipes were changed, use bitbake-diffsigs to compare sigdata files from the "snapshots" to see what change in metadata caused the difference, often it's change in some other dependency, so you need to traverse the dependency tree a bit until you find the real root cause of the difference. On Tue, Dec 19, 2017 at 2:25 PM, Alan Martinovic <alan.martino...@senic.com> wrote: > Hi, > we have a build server set that is used by multiple > people all working on the same yocto project each > having a clone in their working dir. > > The core packages (those coming from meta-openembedded) > are same of every image we build. > > We all share a sstate-cache and a downloads cache. > The download cache works as expected, I only notice > new things being fetched when there were actual changes in > the recipes. > > However, all other steps (do_configure, do_compile, do_package) > seem to be executed arbitrarily without a specific order or cause. > Lot of things are reused from the sstate-cache, some get redone > on random, and a few are always build from the ground. > > I have synced with everyone and confirmed that we're not stepping > on each others toes by cleaning package caches. > > Is there a way to see on what grounds does bitbake chooses > to repeat the steps? > > Be Well, > Alan > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
