[poky] Another staging question

[Tian, Kevin]

>From: Mark Hatle
>Sent: Tuesday, November 09, 2010 11:33 PM
>
>On 11/9/10 7:21 AM, Gary Thomas wrote:
>> I've found another peculiarity with the new staging scheme(*).
>> I have two target platforms, which for all intents and purposes
>> are identical - both are Motorola MPC83xx (e300 core).  The only
>> reason for two target machines is the kernel, plus platform specifics.
>>
>> I built totally from scratch (no SSTATE_MIRRORS) for target machine A.
>> I then tested the staging by building in a new tree, again for machine A.
>> This worked great - the build used mostly the staged packages.  About
>> the only things that were rebuilt were the target specific packages.
>>
>> When I tried it for machine B, again in a totally empty directory, using
>> the 'sstate-cache' directory of the first build as SSTATE_MIRRORS, all of
>> the toolchain was rebuilt (GCC  and friends), but there was no need, the
>> staged version should have been used.
>>
>> Is this expected?
>> What could I do to fix it?
>
>This tells me that the checksumming code found something that it believed
>changed the system behavior.  Likely a machine type or CFLAG or similar.
>
>RP -- is there a way to determine "what changed [and why]" without re-running
>the build?  We found this invaluable when debugging the WR build system's
>checksumming, configuration files and packaging recipes.
>

Just saw this from bottom of my mailbox. "bitbake name -S" will record checksum
for the name and also all the tasks it depends on under tmp/stamps. And then you
can use "bitbake-diffsig" to check the detail. 

Thanks
Kevin