Hello Richard, Tuesday, September 26, 2006, 5:28:15 PM, you wrote:
> Paul's comments in #oe have highlighted the fact that whilst I and > perhaps some others know where things are going (and have come from), a > lot of things are in my head which isn't perhaps the best place for > them. Richard, thanks for this comprehensive discussion. Before rushing with (stupid) questions, I decided to (re)read bitbake-dev and other archives to have clearer picture myself. I've captured what I found at http://www.openembedded.org/bitbakebackground (linked from OE's wiki frontpage). With this overall picture in mind, the changes in bitbake over last year (most of which were led by you) are indeed big and highly improving, and it's IMHO clear that they should be continued, until BitBake and OE metatada would indeed scale well in both perfomance and maintenance. I still don't have general understanding of BitBake internal functioning, but I guess, the best thing I can do is find answer to my specific questions myself in the code. But I have to questions of general nature: 1. What is status of bitbake-ng? IIRC, once info about it was in OE wiki. But now searching for it returns only that it is scheduled topic for OEDEM. So, I guess, exact answers will be known after it, and so far it's in "postponed" state. Well, I cannot say that I personally regret aboy this - it's possible to implement non-so-scalable patterns (or antipatterns) in C as well, but C brings segfaults and higher steep hacking curve with it. Python seems like very perfect language for the tool like BitBake. 2. Using structured secondary storage (i.e. SQL db) as datastore No surprise, I wasn't the first to consider sqlite for the backend ;-) - Holger tried that long ago, https://lists.berlios.de/pipermail/bitbake-dev/2005-May/000018.html So, my question would be: after all the refactors BitBake undergone since that, would sqlite backend be more feasible? But again, I understand, the answer will likely be: "try and see". So, I'm going to understand internal datastructures of BitBake better first. And in the meantime, work on some trivial/small (thanks to Python!) tweaks/improvements. One thing I want to grasp first is unittesting of BitBake. Again, I'm glad there's bitbake-tests directory in BB trunk already. [] > If anyone wants to discuss any of this or better still help with the > code, please do so! > Richard -- Best regards, Paul mailto:[EMAIL PROTECTED] _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
