[poky] sstate status

[Tian, Kevin]

>From: Richard Purdie [mailto:rpurdie at linux.intel.com]
>Sent: Monday, December 06, 2010 9:30 AM
>
>On Sun, 2010-12-05 at 19:10 +0800, Tian, Kevin wrote:
>> Sure. However my remote machine in office is down unexpectedly. I'll verify it later
>> when going to office next week.
>>
>> BTW, on my branch there're also some bug fixes out of environmental variables issue,
>> which could you take a look whether they're correct?
>>
>>
>http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=tk/sstate&id=7a6fc816766
>ea925591a0cf6ae17383a953ae061, siggen.py: set 'runtaskdeps' correctly
>
>I've merged this one, thanks.

Thanks

>
>>
>http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=tk/sstate&id=0a4c46dc2c1
>22ef5c1057380e79b75e302583b4a, siggen.py: fix python error when comparing sstate
>generated from different srcpath
>
>I understand the need for this but I don't like the implementation :)
>
>We can't use OEROOT here as its not a standard variable and is
>deprecated. I was initially thinking POKYBASE but that isn't right
>either in bitbake. Hmm.

Could you elaborate why POKYBASE can't be used too? Because LAYERDIR is a
one-time expansion action? If we're sure that POKYBASE is expanded before
base signature generation, then it could work.

>
>Chris, any suggestions? I'm actually struggling a bit to come up with a
>variable that represents a "head" of the metadata :/. Perhaps filename
>would be enough in this case?
>
>I'd also suggest we remove this path when we save the siginfo file, not
>when we load it and do the comparison.

Yes, that's a better approach. I'll go that approach.

>
>>
>http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=tk/sstate&id=7d6dd0b5717
>b565f478c88d53cf5e53e139f1141, siggen.py: fix the wrong usage on
>BB_TASKHASH_WHITELIST
>
>Why the initial:
>
>if self.twl and not self.twl.search(dataCache.pkg_fn[fn]):
>
>?
>
>I suspect it should just be:
>
>dep_fn = re.search("(?P<fn>.*)\..*", dep).group('fn')
>if self.twl.search(dataCache.pkg_fn[dep_fn]):
>    #bb.note("Skipping %s" % dep)
>    continue
>
>?
>
>For native/cross tasks, I still expect then to have dependencies and be
>rebuilt if something changes, I just don't expect target packages to
>change when native/cross ones do.
>

That's my intention too. Above logic is to filter out native/cross dependencies.
If we do that filter for native/cross tasks too, that means all dependencies 
would be wiped out which is not what we want since they all fall into the
match group. That's why I add the initial condition to restrict the filtering on
on target packages. :-)

Thanks
Kevin