From: Richard Purdie <rpurdie@rpsys.net>
To: bitbake-devel <bitbake-devel@lists.openembedded.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: BitBake changes in the Yocto Project 1.5 cycle
Date: Mon, 22 Apr 2013 15:16:12 +0100 [thread overview]
Message-ID: <1366640172.23738.12.camel@ted> (raw)
I've been giving some thought to where BitBake needs to go in the future
in order to deliver for its users. It started life as a commandline
utility and its grown a lot since it was first created. I think there
are some key decisions that need to be taken to ensure its future
growth.
The first proposal is that we should change the BitBake server so it
becomes memory resident. This means that the first time you run "bitbake
X", the server loads into memory, then subsequent BitBake commands would
just connect to the server and do things. We'd add in some kind of
timeout of say 15 minutes so that it would gracefully exit.
The reason for doing this is simple, it would allow commands to be much
more responsive rather than having the cache/configuration loading each
time which is where our current overhead is. Obviously it would detect
changes to things like MACHINE setting, local.conf and re-parse as
normal in those cases. The intent would be to speed up the interaction
with the system so you don't have the annoying delays/lag.
This would then lead into the second proposal which is to add better
support for new commands. This would be along the lines of some of
Chris' work with bb, the bitbake-env script and so on but with the added
advantage of being able to connect to the server for info. It would
allow us to add query commands for things like the available
PACKAGECONFIG options/settings much more easily than the current
infrastructure. There are some issues about whether these would belong
as part of BitBake or OE and we'd need to figure that out.
The third proposal is to do away with the BitBake wrapper script in
OE-Core for pseudo. Doing this within BitBake is going to be hard and
require some rework but ultimately, I think it will be worth it from a
performance perspective and also stops some of the user confusion about
BitBake running twice (two sets of log files and so on).
These changes should also be in keeping with the expanded UI work and
options such as WebHob and allowing remote use of multiple UIs connected
to servers.
Feedback/comments/suggestions etc./ welcome as always.
I've cc'd the OE-Core list but further discussion should be taken to
bitbake-devel.
Cheers,
Richard
next reply other threads:[~2013-04-22 14:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-22 14:16 Richard Purdie [this message]
2013-04-22 19:12 ` BitBake changes in the Yocto Project 1.5 cycle Marcin Juszkiewicz
2013-04-23 9:04 ` Richard Purdie
2013-04-23 9:27 ` Marcin Juszkiewicz
2013-04-23 9:31 ` Robert Yang
2013-04-23 10:02 ` Hauser, Wolfgang (external)
2013-04-23 9:28 ` [bitbake-devel] " Robert Yang
2013-04-23 8:13 ` Peter Kjellerstedt
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=1366640172.23738.12.camel@ted \
--to=rpurdie@rpsys.net \
--cc=bitbake-devel@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox