On 11/06/12 17:29, Paul Eggleton wrote: > On Monday 11 June 2012 06:53:32 Khem Raj wrote: >> On 6/11/2012 12:29 AM, Tomas Frydrych wrote: >>> I find that -c clean does not work very well, afterward the package >>> gets recompiled but instead of the actual package packages being >>> rebuilt, an earlier version of the packages gets pulled out of >>> sstate into the image. I definitely saw this behaviour with Yocto >>> kernels, but I think happens with other packages as well; I always >>> do -c cleansstate now to avoid this. >> >> yes thats the intended behavior if nothing changed that ensues a >> recompile then it will use precompiled sstate for the package > > To clarify, it's designed to be able to determine when the recipe has changed > in such a way that it needs to be rebuilt (by building up dependencies > between > variables and computing a checksum of the value of each one, which ends up in > a checksum for each task); if it sees no change then the previous task output > will be used from the sstate cache. It's worth noting however that until > recently (post-1.2) we did not handle when local files referred to in SRC_URI > changed. There also still may be other circumstances under which changes to > the recipe or variables which it refers to will not change the sstate > checksums; if you come across a situation where you made a change and sstate > was re-used when you expected it to be rebuilt, please raise it.
Over years of working with Poky I have developed this sort of a normal work flow: bitbake -c devshell <package> < do some tweaking > bitbake -c compile -f <package> bitbake <package> <---- this pulls package from sstate!!! scp ... < test, repeat> This no longer works, even after a forced recompile, Poky just pulls a package out of sstate. It seems the only reliable way to force a package rebuild is either to cleansstate or bump the PR, neither of which is viable an option in the above scenario. What am I missing? Is this really intended? Tomas _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
