8523 2015-10-15 15:28:36 +0000 [regression] d.setVar() + d.delVar() affect _overrides 2015-10-16 10:30:43 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED NOTABUG Undecided normal --- 1 enrico.scholz richard.purdie poky.bs.watcher poky.watcher --- Regression (Used to work) Don't know oldest_to_newest 55362 0 enrico.scholz 2015-10-15 15:28:36 +0000 When modifying a variable with 'd.setVar()' or 'd.delVar()', _override variants seem to be changed too. E.g. script below gives with old bitbake 'good' while recent master (c7cb8255d0) gives 'none': ---- LICENSE = "XX" VAR_cond0 = "good" python () { d.delVar('VAR') d.setVar("OVERRIDES", "cond0"); d.finalize(False) bb.warn("--> %s" % d.getVar("VAR", True)) } ---- $ ./bitbake --version BitBake Build Tool Core version 1.28.0 $ ./bitbake -b test.bb ... WARNING: --> None --- $ ./bitbake --version BitBake Build Tool Core version 1.26.0, bitbake version 1.26.0 $ ./bitbake -b test.bb ... WARNING: --> good 55384 1 richard.purdie 2015-10-16 10:14:07 +0000 This is as a result of the overrides code changes. You can get the old behaviour if you use setVar(xxx, parsing=True) which is what bitbake is doing internally. This was given a lot of long hard thought about what the user really wants/needs and what the current metadata assumed. It seemed that in 99.9% cases outside of the bitbake core, it would be more useful to affect overrides than not and most code I tested against didn't have any issues with the behaviour. I think what ended up convincing me that this was the right way to go was that otehrwise, there is no way to undo overrides. The user clearly does actually need/want to do that in many scenarios. With the parameter you can do both. Admittedy its not well documented yet, I'm torn on whether it should be a publicly used API or not, although that is probably inevitable. 55387 2 enrico.scholz 2015-10-16 10:30:43 +0000 is 'parsing=True' for delVar() planned too?