On Wed, 2019-10-02 at 16:25 +0100, [email protected] wrote: > I've queued such a patch in master-next and am testing, its an > improvement but I'm worried its not resolving the problem. > > Options are to prune the sstate cache, or to teach the code to > generate > the full filenames (would mean refactoring)... > > We could give you access to the autobuilder to help reproduce the > problem but I think its clear where the delays are...
We've cleaned out the sstate on the autobuilder to try and reduce the impact of this issue as this patch, whilst helping, didn't solve the problem. I'm wondering about a different approach. Just to elaborate on what teaching the code would entail, as well as using the 'hashfn' data as part of the hash validate function in from runqueue.py: sq_data['hashfn'][tid] = self.rqdata.dataCaches[mc].hashfn[taskfn] we could inject that data into BB_TASKDEPDATA. If we did that, the oecore code could probably create the full sstate tasknames for the tasks it needs using logic extracted out of sstate_checkhashes() from sstate.bbclass. This would mean the script wouldn't have to guess at filenames, it could access them directly. Worth some further thought... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
