[OE-core] Hash Equivalency - What this means for developer productivity

[Richard Purdie]

On Fri, 2019-08-02 at 16:53 +0100, Richard Purdie wrote:
> With the patches in master-next and this configuration in local.conf:
> 
> BB_HASHSERVE = "localhost:0"
> BB_SIGNATURE_HANDLER = "OEEquivHash"
> 
> $ bitbake core-image-sato
> $ bitbake m4-native -c install -f
> $ bitbake core-image-sato
> 
> will result in do_populate_sysroot of m4-native running, it will see
> the output matches the previous build and it will then skip to the
> rootfs generation pulling all the other pieces from sstate.
> 
> Note that for this to work, m4-native has to have previously built
> with the hashserv running, otherwise it has nothing to compare its
> output to.
> 
> I think this should be a "big deal" for many developers, reducing
> unneeded rebuilds and hence speeding up development.

I should have mentioned, this code relies on reproducibile builds as
its comparing the binary output. The more reproducibile builds are, the
more likely sstate reuse will happen.

This is one reason reproducibile builds are important!

We may want to look at more interesting comparison mechanisms in the
future like the APIs exposed by libraries. Having support for matching
"equivalent" binaries in the core is the key first step to these things
though.

Cheers,

Richard