MokoMakefile make update forces Bitbake cache rebuild

Rod Whitby rod at
Mon Apr 2 04:56:20 CEST 2007

Henryk Plötz wrote:
> a make update followed by make always forces a complete rebuild of the
> Bitbake cache which takes quite long, too long. (Plus: As a x86_64 user
> I'm not entitled to using Psyco.)

Yes, this is something we do want to fix.

> In principle this rebuild should not be necessary since bitbake keeps
> dependency and timestamp information about its cache to only rebuild
> those parts that have changed or depend on changed parts.


> After a
> cursory look I think this rebuild is due to MokoMakefile calling quilt
> which modifies the time stamp on some files, including base.bbclass.
> (Almost?) All bitbake recipes depend on base.bbclass, so modifying it
> will necessitate a comple cache rebuild.

Yes, this is due to make update reapplying the patches after updating
from svn.

> Is this really necessary? Can make update be modified to not touch the
> modification times of all files that it doesn't actually change?

I couldn't think of an easy way to do it, but I'm open to other inputs.

I don't want to put the end-user into a situation where they need to
manually resolve merges.  Therefore we need to unapply any mokomakefile
patches before updating from the openmoko svn and then reapplying that

The openmoko-mirrors patch is one culprit.  We may even be able to
remove that patch if the OM team has added the sources site as a
premirror ...

The silence-retrieved-revisions patch is the other culprit.  This seemed
to be debugging information that was output during the bbfile parsing.
Perhaps mickeyl could add that patch permanently to the openmoko svn ...

I'll look at removing both those patches and see if that stops the cache

-- Rod

More information about the community mailing list