[OE-core] [PATCH] Checksums for local files now stored using partial recipe path

[Jate Sujjavanich]

> As far as I can tell though that won't actually fix the issue triggering
> rebuilds in your case. Something else must be changing. It would be
> interesting if you could dig into what that might be as I can't
> reproduce the rebuilding issue here.

I discovered that different versions of Dylan from git and the tarball were causing the rebuilds to occur. Once I had the exact same version of dylan, the entire build was pulled from sstate-cache.

My understanding now is that the recipe file dependencies changed for some recipes. Therefore the sorted checksums were modified triggering a rebuild.

> As I said earlier, if you look at the code only the checksum value goes
> into the task checksum and not the filename, so the path to the base of
> the metadata changing cannot influence the task checksum. However, I
> think I can see how you would think that the paths changing influenced
> the checksum, since the data that we put into the siginfo file *does*
> contain the full path, and thus bitbake-diffsigs will report that as
> having changed even though that difference didn't change the task
> checksum. That is a bug and we should fix how we store paths either in
> the cache or in the siginfo file, but that fix will have to take into
> account different layer paths. I'd suggest a simpler and more reliable
> approach would be to just get the relative path to os.path.dirname of
> the recipe rather than TOPDIR.

The full paths were a little confusing. I bet that the checksum differences (or other changes) were at the bottom of the diffsigs output.

I have not had a chance to look at this again closely. When I do, I'll check out your suggestions.


- Jate S.