Another staging question

Another staging question

[Gary Thomas]

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?

Thanks

(*) I'm very happy that the new staging is starting to work better.
As is, it's a great leap forward;  I'm just hopeful that the remaining
kinks can be worked out.  I'll be glad to help in this any way I can.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Another staging question

[Mark Hatle]

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.

--Mark

> Thanks
>
> (*) I'm very happy that the new staging is starting to work better.
> As is, it's a great leap forward;  I'm just hopeful that the remaining
> kinks can be worked out.  I'll be glad to help in this any way I can.
>

Re: 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