|author||Chris Larson <email@example.com>||2010-06-10 10:35:31 -0700|
|committer||Chris Larson <firstname.lastname@example.org>||2010-09-03 18:51:54 -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 Signed-off-by: Chris Larson <email@example.com>
Diffstat (limited to 'TODO')
1 files changed, 9 insertions, 8 deletions
@@ -15,14 +15,15 @@
exception like that, *perhaps*, to abstract away exceptions raised by
event handlers, but it has no place in bb.build.exec_task
-- Leverage the python logging module
-- Convert bb modules to stop using the bb.msg functions.
-- Switch the messaging wrappers in the bb package to use the logging module
- directly, as we'll be deprecating the bb.msg versions, but these should
- stay around for the metadata to use.
-- Deprecate the bb.msg functions.
-- Should we use the logging module rather than print in the knotty ui?
+- BUG: if you chmod 000 local.conf, it silently doesn't parse it, when it
+ should really fail, so the user can fix the problem.
+- Audit bb.fatal usage - these should all be able to be replaced with
+- Add deprecation warnings to the bb.msg functions
+- Figure out how to handle the ncurses UI. Should some of our logging
+ formatting stuff be made common to all of bitbake, or perhaps all UIs via
+ the UIHelper?
Long term, high impact: