[oe] Bitbake past, present and future [long]

[Paul Sokolovsky]

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:pmiscml at gmail.com