[OE-core] [bitbake-devel] Complete rebuilds due to random hashes

[Richard Purdie]

On Fri, 2012-12-07 at 11:26 +0100, Enrico Scholz wrote:
> Hello,
> 
> I have encountered the problem the whole distribution gets rebuilt when
> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
> 
> Dumping data in _build_data() (siggen.py) revealed that sometimes a
> gitpkgv_do_configure() (or _do_compile/install...) function is in the
> deps, sometimes not.  The recipes where this happens (e.g. m4) do not
> inherit gitpkgv and it is not included globally either.
> 
> Further debugging[1] shows
> 
> | ERROR: calledvar=autotools_do_configure, vars=[['gitpkgv_do_configure', 'autotools_do_configure'], ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure', 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None, 'gitpkgv', 'autotools']
> 
> for such a recipe (note the 'gitpkgv_do_configure')
> 
> 
> For me, it seems that this depends on the (random) order in which recipes
> are read.  E.g. when a recipe using 'gitpkgv' is read first, the global
> 'classes' array will contain 'gitpkgv' and ExportFuncsNode() is constructed
> with it.
> 
> But when m4 is read before the first recipe using 'gitpkgv', it won't be
> contained in 'classes' and the corresponding ExportFuncsNode() will not
> create this variable.
> 
> 
> Does somebody know how to fix this?

Actually, I think I do have theory for what is happening. I think there
is some kind of exception happening in one of your recipes which is
perhaps causing it to be skipped/ignored and this is corrupting the
state of the parser.

I'm guessing the classes variable in BBConfHandler.py isn't getting
reset to [None, ] and hence the next recipe to be parsed sees "oddness"
due to the field not being reset.

This would happen in the classes.remove(__classname__) line never get
called, which would happen if statements.eval(d) or some other part of
the processing failed.

I would add some debug code into gitpkgv.bbclass around the functions
there, perhaps a try:/except: and see if there is some kind of uncaught
exception happening for one of your recipes. If that isn't it, I would
be intersted to understand what you have which is breaking out the
fetcher. It could be a SkipPackage exception under some circumstance for
example.

This would explain the cause, we then need to fix the parser state
engine so its properly reset each time...

Cheers,

Richard