| Submitter | Enrico Scholz |
|---|---|
| Date | Dec. 7, 2012, 10:26 a.m. |
| Message ID | <lyfw3ii2ef.fsf@ensc-virt.intern.sigma-chemnitz.de> |
| Download | mbox | patch |
| Permalink | /patch/40643/ |
| State | New |
| Headers | show |
Comments
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'] I'm struggling to figure out how the code is doing this. The most interesting piece here is: classes=[None, 'gitpkgv', 'autotools'] and I cannot get a recipe locally to do this. classes is basically set from BBConfHandler and its a relatively simple codepath. This would imply the gitpkgv class is doing an "inherit autotools"? Can you show how you're using gitpkgv in your code and what the bbclass contains? I have the version from meta-oe but I'm failing to reproduce or explain how this would get into there... Are you doing anything interesting with EXPORT_FUNCTIONS anywhere in your code? Its very odd and any more information about your configuration would be helpful in reproducing/debugging this. Cheers, Richard
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
Richard Purdie <richard.purdie@linuxfoundation.org> writes: >> 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. > ... > 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. Sorry, my fault. I patched bitbake to ignore SkipPackage[1] and missed that the global 'classes' variable was not reset. fwiw, patch was required to allow 'gitpkgv' recipes to be skipped e.g. because no git branch exists for the corresponding setup. Expansion of PV will fail in this case with a fetcher error. Enrico Footnotes: [1] https://github.com/ensc/bitbake/commit/fe0093b34dabe979c81a9b428de96ba73a4e3edb (working variant)
Patch
--- a/lib/bb/parse/ast.py +++ b/lib/bb/parse/ast.py @@ -207,6 +207,8 @@ class ExportFuncsNode(AstNode): for flag in [ "func", "python" ]: if data.getVarFlag(calledvar, flag): + if var == 'gitpkgv_do_configure': + bb.error("calledvar=%s, vars=%s, allvars=%s, classes=%s" % (calledvar,vars,allvars,self.classes)) data.setVarFlag(var, flag, data.getVarFlag(calledvar, flag)) for flag in [ "dirs" ]: if data.getVarFlag(var, flag):