Hi Holger, Thanks for the response :)
On Sun, 2007-08-12 at 01:40 +0200, Holger Freyther wrote: > I don't think this is a recent regression. What I can say is that > bb.data.update_data (or whatever this method was called) is a > relative cheap operation. So technically there would be nothing > preventing us from adding it. Agreed, its not a new problem but one I did notice something going wrong with due to the infotroduction of SRCREV and the way it interacted with exmap-console. > I'm certain that we will see funny/unexpected things with the OE > metadata when calling update_data on immediate assignments, so if you/ > we decide to do it I would propose the following strategy. > > Use the existing bitbake and pickle/dump each parsed file, then use > the new bitbake and pickle/dump each parsed file as well. Then run a > small algorithm (I think I have comitted it to bb.data) to diff two > smart_data dictionaries. > > I think it is fine to change that, specially as update_data is quite > cheap nowadays, but I would like to see the difference in our metadata. Agreed. We need to find a way of checking changes like this so perhaps we should create some kind of semi-automated test for this. Just for reference, I checked the number of immediate expansions present in OE. We have 97 of them of which 23 are in conf/class files and 8 of those are calls to bb.fatal. Of the ones in packages I can see at least 5 which are just plain wrong... Looking at the list of variables, my gut feeling is we can change this without breaking anything but I agree we need to check. Cheers, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
