Re: [PATCH 0/2] Signature-based rebuild improvements

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

On Tue, 2012-06-19 at 06:43 -0500, Jason Wessel wrote:
> On 06/18/2012 10:45 AM, Paul Eggleton wrote:
> > The following changes (against poky, but apply cleanly with -p2 against
> > bitbake master) are available in the git repository at:
> > 
> >   git://git.yoctoproject.org/poky-contrib paule/bb-forcebuild
> >   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/bb-forcebuild
> > 
> > Paul Eggleton (2):
> >   bitbake: ensure -f causes dependent tasks to be re-run
> >   bitbake: add -C option to invalidate a task and rebuild the target
> > 
> >  bitbake/bin/bitbake        |    3 +++
> >  bitbake/lib/bb/build.py    |   18 ++++++++++++++++++
> >  bitbake/lib/bb/cooker.py   |    6 +++---
> >  bitbake/lib/bb/runqueue.py |   28 ++++++++++++++++++++++------
> >  bitbake/lib/bb/siggen.py   |   35 +++++++++++++++++++++++++++++++++++
> >  5 files changed, 81 insertions(+), 9 deletions(-)
> 
> While the use cases described in the defect work, there is a new side
> effect.  The sstate dir starts to fill up with new sums for the what
> ever package you compile.  Perhaps this is some kind of trade off we
> have to live with, but I do thing it is worth discussing.
>
> I start with a fully populated sstate.  I didn't make any code changes
> at all to any package, I just wanted to see the compile log from acl
> in this case.
>
>     bitbake -f -c compile acl
>     bitbake acl
>
> The sstate sum is completely different due to the hash injection, but
> the code compiled for everything is the same.  There is probably no
> easy, cheap (as in cpu/wall time) way to have the best of both worlds.

I think this fix is good and solves various immediate problems. Thinking
forward to the future, if you can know the state of a code base as a
checksum, you could inject that as the "taint" and then you would be
able to match two existing matching compiles. Having everything under
git control for example would be a cheap way to do this, if you can
gurantee that all changes were encapsulated.

For the menuconfig example, I did wonder about checksumming the new
defconfig and injecting that for example.

What I like about the architecture of the taint implementation is that
it doesn't preclude any of the above so its something we can think about
and work towards if we can come up with a good enough plan :)

Cheers,

Richard