On Wed, 2018-12-05 at 22:50 +0000, Richard Purdie wrote: > On Mon, 2018-12-03 at 21:42 -0600, Joshua Watt wrote: > > Abstracts the function to get the dependency ID for a task so it > > can > > return something other that the taskhash > > > > [YOCTO #13030] > > > > Signed-off-by: Joshua Watt <jpewhac...@gmail.com> > > --- > > bitbake/lib/bb/siggen.py | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/bitbake/lib/bb/siggen.py b/bitbake/lib/bb/siggen.py > > index ab6df7603c8..2daca70538a 100644 > > --- a/bitbake/lib/bb/siggen.py > > +++ b/bitbake/lib/bb/siggen.py > > @@ -41,6 +41,9 @@ class SignatureGenerator(object): > > def finalise(self, fn, d, varient): > > return > > > > + def get_depid(self, task): > > + return self.taskhash[task] > > + > > def get_taskhash(self, fn, task, deps, dataCache): > > return "0" > > I spent a while wondering why we still had "IDs" in the runqueue code > when I thought I'd removed them all. Once I'd gotten over that I
I suppose I'm not familiar enough with bitbake's history to have understood that these "IDs" were problematic in the past :) > somehow thought this related to the task's dependencies and then how > could it only have one of them? > > I therefore suspect calling this "depid" is going to be confusing and > we need a better name for it. I'm wondering about taskresid? > taskresolvid? taskresolvedid? taskreshash? > > I appreciate why you're calling it an 'ID', hash may be clearer > thought, not sure... Ya, I struggled with the naming. There is no reason it has to be a hash, so I went with a (probably too generic) "ID"... in practice using a hash is reasonable so I don't have a problem using "hash" in the name. My runner up names were "dephash" or "taskdephash". I think indicating that it is involved in the dependency calculations is important, although I can see how it might be some confusion about where it is involved. I'm not too keen on the "resolved" names... but maybe I'm missing where the are stemming from? Another option if you want to go more of the graph theory approach might be "taskedgehash", "edgehash", "taskedgeid", "edgeid", etc. > > Cheers, > > Richard > > > > > > > > > > -- Joshua Watt <jpewhac...@gmail.com> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
