All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: Using the OpenEmbedded metadata to build Linux Distributions
	<openembedded-devel@openembedded.org>,
	bitbake-dev@lists.berlios.de
Subject: Re: Bitbake past, present and future [long]
Date: Mon, 2 Oct 2006 16:00:11 +0300	[thread overview]
Message-ID: <192578441.20061002160011@gmail.com> (raw)
In-Reply-To: <1159280896.5573.123.camel@localhost.localdomain>

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@gmail.com




  reply	other threads:[~2006-10-02 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-26 14:28 Bitbake past, present and future [long] Richard Purdie
2006-10-02 13:00 ` Paul Sokolovsky [this message]
2006-10-02 13:55   ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=192578441.20061002160011@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=bitbake-dev@lists.berlios.de \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.