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
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.
is 'parsing=True' for delVar() planned too?