Chris Larson [Fri, 10 Dec 2010 23:53:19 +0000 (16:53 -0700)]
Rename command events, adjust compareRevisions
- Moved the logic for comparing revisions from cooker into command
- Removed 'Cooker' from the event names
- Renamed the 'ExitCode' event into CommandExit, and changed CommandFailed to
be a subclass of CommandExit
Chris Larson [Fri, 10 Dec 2010 15:51:47 +0000 (10:51 -0500)]
Kill the uncaught exception handler
We now wrap the main() in a try/except, ensuring that both the main portion of
bin/bitbake and the UI raising an exception will be shown to the user. For
the server and workers, we can ensure in the server itself that exceptions are
handled correctly.
Chris Larson [Tue, 23 Nov 2010 22:30:45 +0000 (15:30 -0700)]
cooker: use re match, not search in re_match_strings
We want to match the requested pattern at the beginning of the string,
otherwise things behave in an unintuitive manner wrt ASSUME_PROVIDED (e.g.
ASSUME_PROVIDED += "gtk+" will also assume foo-gtk+ is provided), and the user
can always use '.*gtk+' to get the old behavior.
Chris Larson [Tue, 30 Nov 2010 15:25:13 +0000 (08:25 -0700)]
cooker: no cached in progressbar and add ETA
Rather than updating the progress bar based on the recipe being processed
(whether cached or parsed), consider only parsed recipes. This reduces the
instability in progress rate introduced by the cached entries, and allows the
ETA to be resurrected and be a bit more useful.
Chris Larson [Tue, 23 Nov 2010 19:02:40 +0000 (14:02 -0500)]
knotty: drop the ETA from the progressbar for now
Currently, the progress bar is an indication of the processing of our recipes,
which includes loading the cache file, then for each recipe, either adding the
existing cached information to the CacheData or parsing the recipe from disk.
These tasks clearly take different amounts of time, so the ETA is unreliable
today. We'll resurrect this functionality after we revamp the progress
handling, fully incorporating the load of the cache file.
Chris Larson [Tue, 23 Nov 2010 17:46:49 +0000 (11:46 -0600)]
cooker: ensure that the cache sync completes
Without explicitly joining the thread, it's possible for the process to end
(e.g. after a bitbake -p) and kill off the thread without waiting for it to
exit cleanly. So, register the thread join with atexit.
Chris Larson [Sun, 21 Nov 2010 18:59:05 +0000 (11:59 -0700)]
cooker: show progress bar before initializing the cache
This ensures that the time spent loading the cache from disk occurs with the
progress bar up. Though the progress bar stays at 0% during this period, I
think this is an improvement over the multi-second stall which occurred
previously before the progress bar came up. Ideally, we'd integrate cache
loading from disk into the progress display, but this is a first step.
Chris Larson [Fri, 19 Nov 2010 18:46:42 +0000 (11:46 -0700)]
cooker: stop loading the cache for -b
Previously, the cache was actually being loaded from disk twice whenever using
-b or -e -b. This also moves the bb_cache instance into the CookerParser, as
it's not needed by the cooker itself at all.
Chris Larson [Fri, 19 Nov 2010 05:47:36 +0000 (22:47 -0700)]
cache: sync the cache file to disk in the background
This version uses a thread rather than a process, to avoid problems with
waitpid handling. This gives slightly less overall build time reduction than
the separate process for it did (this reduces a -c compile coreutils-native by
about 3 seconds, while the process reduced it by 7 seconds), however this time
is quite insignificant relative to a typical build.
The biggest issue with non-backgrounded syncing is the perceived delay before
work begins, and this resolves that without breaking anything, or so it seems.
Chris Larson [Fri, 19 Nov 2010 05:28:09 +0000 (22:28 -0700)]
Simplify cache syncing
Rather than adding nocache items to the cache, then copying the cache and
removing them to sync it, don't add them in the first place. Also use 'with'
for the cachefile.
Chris Larson [Fri, 19 Nov 2010 03:21:54 +0000 (20:21 -0700)]
Implement parallel parsing support
This utilizes python's multiprocessing module. The default number of threads
to be used is the same as the number of available processor cores, however,
you can manually set this with the BB_NUMBER_PARSE_THREADS variable.
Chris Larson [Wed, 17 Nov 2010 04:55:19 +0000 (21:55 -0700)]
cache: don't write out the cache unnecessarily
If the only recipes's we reparsed this run were those flagged as not to be
cached, there's no point in re-saving the cache, as those items won't be
included anyway.
Chris Larson [Tue, 16 Nov 2010 19:58:52 +0000 (12:58 -0700)]
cache: create and use a RecipeInfo class
This class holds the particular pieces of information about a recipe which are
needed for runqueue to do its job.
By using it, I think we improve code clarity, reduce method sizes, reduce
overuse of primitive types, and prepare for parallel parsing. In addition,
this ditches the leaky abstraction whereby bb.cache attempted to hide the
difference between cached data and a full recipe parse. This was a remnant
from the way things used to be done, and the code using it had to know the
difference anyway. If we choose to reimplement caching of the full recipes,
we can do it in bb.parse, in a completely transparent way.
Bob Foerster [Fri, 19 Nov 2010 20:39:22 +0000 (04:39 +0800)]
Prefer xrange over range for small performance gain.
range() allocates an actual list when called. xrange() is just an iterator
and creates the next range item on demand. This provides a slight
performance increase.
In python 3, range will do what xrange does currently, but the upgrade will
be handled by the 2to3 tool.
Peter Chubb [Thu, 3 Sep 2009 17:31:40 +0000 (17:31 +0000)]
Allow mercurial fetcher to follow tip
There are occasions when developing when I want a package always to
grab the latest copy of a package. Witht eh CVS fetcher you can do
this by setting the `date' tag to `now'. This patch adds similar
functionality to the mercurial fetcher: if the revision to fetch is
`tip' then always grab from the server, and don't use the cached
tarball.
Signed-off-by: Peter Chubb <peter.chubb@nicta.com.au> Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Chris Larson [Thu, 4 Nov 2010 15:47:11 +0000 (08:47 -0700)]
Fix GraphViz .dot output for rdepends and rrecs
Use bb.utils.explode_deps to break up the rdepends and rrecommends strings.
This fixes the same issue which was fixed by a number of patches floating
around, but uses explode_deps rather than regular expressions.
Eric BENARD [Mon, 6 Sep 2010 08:51:52 +0000 (08:51 +0000)]
bitbake: lib/bb/fetch/hg: fix fetching from a mercurial repository
* without this fix, we get :
updating working directory
74 files updated, 0 files merged, 0 files removed, 0 files unresolved
abort: There is no Mercurial repository here (.hg not found)!
Signed-off-by: Eric Bénard <eric@eukrea.com> Tested-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Chris Larson [Tue, 28 Sep 2010 15:24:55 +0000 (08:24 -0700)]
Queue up events before the UI is spawned
- Queue up any events fired to the UI before the UI exists
- At exit, check if UIs exist, and if not, flush the queue of LogRecords to
the console directly.
- When establishing a connection from the UI to the server, flush the queue of
events to the queue in the server connection, so the UI will receive them
when it begins its event loop.
Chris Larson [Fri, 10 Sep 2010 18:34:39 +0000 (11:34 -0700)]
Fix bitbake -k issue introduced by build exception cleanup
A SystemExit from a python function wasn't being raised as a FuncFailed, which
resulted in it not being caught by the exception handlers in the runqueue for
the worker process, which resulted in a SystemExit exit, rather than os._exit,
which causes all manner of problems when used in a forked process. This fixes
it by ensuring we raise a FuncFailed when seeing exceptions which aren't
instances of Exception.
Chris Larson [Fri, 10 Sep 2010 18:14:54 +0000 (11:14 -0700)]
Fix exit code display for task failure
Per the python documentation, os.waitpid returns the exitcode shifted up by 8
bits, and we weren't compensating, resulting in a display of 'failed with 256'
when a worker process exits with a code of 1.
Chris Larson [Fri, 10 Sep 2010 01:03:40 +0000 (18:03 -0700)]
Simplify build exception handling
- Drop EventException
- Use FuncFailed as the primary function failure exception, using TaskFailed
for the event (leaving it up to the process running exec_{func,task} to
display the more detailed information available in the exception).
- Switch InvalidTask to an exception rather than an event, as that's a
critical issue.
- Reduce the number of messages shown to the user when a task fails -- they
don't need to be told it fails 12 times. Work remains in this area though.
Chris Larson [Thu, 10 Jun 2010 17:35:31 +0000 (10:35 -0700)]
Switch bitbake internals to use logging directly rather than bb.msg
We use a custom Logger subclass for our loggers
This logger provides:
- 'debug' method which accepts a debug level
- 'plain' method which bypasses log formatting
- 'verbose' method which is more detail than info, but less than debug
Chris Larson [Thu, 10 Jun 2010 15:05:52 +0000 (08:05 -0700)]
Use logging in the knotty ui, and pass the log record across directly
This kills firing of Msg* events in favor of just passing along LogRecord
objects. These objects hold more than just level and message, but can also
have exception information, so the UI can decide what to do with that.
As an aside, when using the 'none' server, this results in the log messages in
the server being displayed directly via the logging module and the UI's
handler, rather than going through the server's event queue. As a result of
doing it this way, we have to override the event handlers of the base logger
when spawning a worker process, to ensure they log via events rather than
directly.
