Re: How to move a recipe to another directory without invalidating its sstate-cache?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.

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?

Cheers,

Richard