[OE-core] How to move a recipe to another directory without invalidating its sstate-cache?

[Mike Looijmans]

On 16-12-15 14:33, Richard Purdie wrote:
> On Wed, 2015-12-16 at 14:18 +0100, Mike Looijmans wrote:
>> On 16-12-15 13:35, Richard Purdie wrote:
>>> On Wed, 2015-12-16 at 10:38 +0100, Mike Looijmans wrote:
>>>> I renamed "recipes-some/foo/bar.bb" to "recipes
>>>> -some/buzz/bar.bb"
>>>>
>>>> Rebuilding bar and its dependencies will take about 16 hours. So
>>>> I
>>>> don't want
>>>> to trigger a rebuild.
>>>>
>>>> running "bitbake -S printdiff bar" only reveils this:
>>>
>>> I'm not sure I trust the output of -S printdiff, there are some
>>> cases
>>> it doesn't seem to "guess" right. I wish I or someone one could fix
>>> but
>>> but we can do its work manually. Can you try something like:
>>>
>>> set TMPDIR = "x"
>>> bitbake -S bar
>>> rename the recipe
>>> set TMPDIR = "y"
>>> bitbake -S bar
>>
>> Found out I need an extra "none" in here:
>> bitbake -S none bar
>
> Sorry, yes.
>
>>> then
>>>
>>> "ls tmp-x/stamps/xxxx/bar"
>>> "ls tmp-y/stamps/xxxx/bar"
>>>
>>> and see which tasks change signature. Then run:
>>>
>>> "bitbake-diffsigs <sig A> <sig B>"
>>>
>>> and see if that makes more sense?
>>
>> That gave the same output. Everything after "runtaskdeps" is bogus
>> because its
>> value changes from [blahblah, foobar] into [buzbar, blahblah] and now
>> diffsig
>> seems to attempt to match the "blahblah" signatures against those of
>> "buzbar".
>>
>> Which sort of hints that if my new name starts with an "f" the
>> reordering
>> won't happen, so I'm gonna try renaming to "fbuz" now,,,
>
> I still suspect this might be the way the tool displays the data rather
> than the real problem as there is some fuzziness in the data that code
> has to work with. Bitbake just knows there are dependencies on hashes
> X, Y, Z and it has to try and guess how to match them up. The paths are
> included to help reduce fuzz but are only used by the analysis code,
> not the checksum creation.

No, if the sort order doesn't change, the checksum remains the same as well.

So if i rename "foo" to "far" it will not rebuild the package (using plain 
bitbake without -S switches), but if I rename "foo" to "buz" it will rebuild 
because there's a dependent package that sorts before "far" but after "buz".


> Did the hashes themselves change or just the paths? I'm wondering if
> the order that bitbake adds the checksums to the main checksum may have
> some bearing on this...
>
> Being able to see some real data would also help. Does this reproduce
> with a public recipe I can see the real data for?

There should be quite a few recipes in OE-core that might match this pattern:

Recipe X must depend on recipe Y. The directory of Y sorts before that of X. 
Renaming the directory of X to something that sorts before that of Y should 
trigger the problem.

I'll see if I can locate an existing one.

M


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail