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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
