[OE-core] [bitbake-devel] [PATCH v3 13/17] bitbake: runqueue: Pass dependency ID to hash validate

Richard Purdie richard.purdie at linuxfoundation.org
Wed Dec 5 22:52:22 UTC 2018


On Mon, 2018-12-03 at 21:42 -0600, Joshua Watt wrote:
> If the dependency ID is being used to track task dependencies, the
> hash
> validation function needs to know about it in order to properly
> validate
> the hash.
> 
> TODO: This currently isn't going to be backward compatible with older
> hashvalidate functions. Is that necessary, and if so are there any
> suggestions for a good approach?

That is necessary or bitbake and the metadata need to be in lock step.

@@ -1567,15 +1568,16 @@ class RunQueue:
>              sq_fn.append(fn)
>              sq_hashfn.append(self.rqdata.dataCaches[mc].hashfn[taskfn])
>              sq_hash.append(self.rqdata.runtaskentries[tid].hash)
> +            sq_depid.append(self.rqdata.runtaskentries[tid].depid)
>              sq_taskname.append(taskname)
>              sq_task.append(tid)
> -        locs = { "sq_fn" : sq_fn, "sq_task" : sq_taskname, "sq_hash" : sq_hash, "sq_hashfn" : sq_hashfn, "d" : self.cooker.data }
> +        locs = { "sq_fn" : sq_fn, "sq_task" : sq_taskname, "sq_hash" : sq_hash, "sq_hashfn" : sq_hashfn, "sq_depid" : sq_depid, "d" : self.cooker.data }
>          try:
> -            call = self.hashvalidate + "(sq_fn, sq_task, sq_hash, sq_hashfn, d, siginfo=True)"
> +            call = self.hashvalidate + "(sq_fn, sq_task, sq_hash, sq_hashfn, sq_depid, d, siginfo=True)"
>              valid = bb.utils.better_eval(call, locs)
>          # Handle version with no siginfo parameter
>          except TypeError:
> -            call = self.hashvalidate + "(sq_fn, sq_task, sq_hash, sq_hashfn, d)"
> +            call = self.hashvalidate + "(sq_fn, sq_task, sq_hash, sq_hashfn, sq_depid, d)"
>              valid = bb.utils.better_eval(call, locs)
>          for v in valid:
> 

The hint on how we've handled this before is in the code, the TypeError
was the fallback code for older metadata (which you just broke!). We
may need to do something similar here.

Cheers,

Richard



More information about the Openembedded-core mailing list