[OE-core] sstate.bbclass: Ensure machine specific stamps are only wiped for the current task

[Koen Kooi]

Op 10 okt. 2011, om 16:16 heeft Richard Purdie het volgende geschreven:

> On Mon, 2011-10-10 at 13:45 +0200, Martin Jansa wrote:
>> On Sun, Oct 09, 2011 at 08:11:45PM +0200, Koen Kooi wrote:
>>> 
>>> Op 9 okt. 2011, om 20:10 heeft Martin Jansa het volgende geschreven:
>>> 
>>>> On Sun, Oct 09, 2011 at 01:25:09PM +0200, Koen Kooi wrote:
>>>>> 
>>>>> Op 6 okt. 2011, om 16:19 heeft Richard Purdie het volgende geschreven:
>>>>> 
>>>>>> sstate was being a little too ethusiastic about removing stamp files and
>>>>>> was removing stamp files for other machines when it shouldn't have been.
>>>>>> 
>>>>>> This patch teaches sstate about machine specific stamp extensions and
>>>>>> allows it to only remove the current task's stampfiles.
>>>>> 
>>>>> Not sure if it's related to this problem or not but sstate is still not working as intented for me when switching machines, it keeps rebuilding the toolchain when switching machine. What I did this morning:
>>>>> 
>>>>> 1) wipe out tmp, sstate-cache, pseudodone
>>>>> 2) MACHINE=beagleboard bitbake u-boot
>>>>> 3) cp conf/machine/beagleboard.conf conf/machine/brokensstate.conf
>>>>> 4) MACHINE=brokensstate bitbake u-boot
>>>> 
>>>> Same here.. :/ (building 3 armv7 machines.. always "from scratch").
>>> 
>>> To eliminate varables: Angstrom/shr/aurora/micro/other/all of the above?
>> 
>> DISTRO=shr
>> 
>> MACHINE=nokia900 bitbake shr-image -> builds from scratch, finished ok
>> MACHINE=palmpre bitbake shr-image -> builds from scratch, finished ok
>> MACHINE=palmpre2 bitbake shr-image -> builds from scratch, finished ok
>> 
>> without wiping anything (same tmp, same sstate-cache, same pseudodone)
>> 
>> MACHINE=palmpre bitbake shr-image -> builds from scratch, again!, finished ok
>> MACHINE=palmpre2 bitbake shr-image -> builds from scratch, again!, finished ok
>> MACHINE=nokia900 bitbake shr-image -> builds from scratch, again!, finished ok
>> 
>> palmpre and palmpre2 are "the same"
>> $ cat meta-smartphone/meta-palm/conf/machine/palmpre.conf | grep -v ^#
>> require conf/machine/include/palmpre.inc
>> 
>> $ cat meta-smartphone/meta-palm/conf/machine/palmpre2.conf | grep -v ^#
>> require conf/machine/include/palmpre.inc
>> 
>> nokia900 is also armv7a-vfp-neon (that's why all packages except
>> MACHINE_ARCH were always reused without rebuilding in OE-classic).
>> 
>> I have tried to debug sigdata files to see why and also tried to add
>> MACHINEOVERRIDES[vardepsexclude] = "MACHINE"
>> as RP suggested, but sofar haven't found solution at least to reuse
>> already built sstate packages for armv7a-vfp-neon.
> 
> Also as a tip for debugging this, you can do what is in the following
> commit (patch also inline below):
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip9&id=1261cc69b152f33b934c2448020dfa3c95f312c6
> 
> which will mean bitbake -n generates stamp files for a given bitbake
> run. You can then quickly do:
> 
> MACHINE=A bitbake -n foo
> MACHINE=B bitbake -n foo
> 
> for example and then look for cases where two stamp sigdata files were
> generated. If you see them you can "bitbake-diffsigs A B" and I'll be
> very interested in the results of that and "bitbake-diffsigs A"...
> 
> Cheers,
> 
> Richard
> 
> bitbake: Allow easier dry run stamp debugging
> 
> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> ---
> diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py

This seems to be against poky instead of bitbake and doesn't apply against bitbake master:

koen at dominion:/OE/tentacle/sources/bitbake$ patch -p2 < dry 
patching file lib/bb/build.py
Hunk #1 succeeded at 257 (offset 2 lines).
Hunk #2 succeeded at 319 (offset 2 lines).
Hunk #3 succeeded at 360 (offset 2 lines).
patching file lib/bb/runqueue.py
Hunk #1 FAILED at 1156.
1 out of 1 hunk FAILED -- saving rejects to file lib/bb/runqueue.py.rej