path: root/TODO
diff options
authorDavid Reyna <David.Reyna@windriver.com>2018-05-14 20:24:44 -0700
committerDavid Reyna <David.Reyna@windriver.com>2018-05-14 20:24:44 -0700
commit104205bf64d7784874f1c94a3e3448a67ceb6725 (patch)
tree59cd2293f077eff566dadb629be51abd9e73acb3 /TODO
parentc6749b09cafccf001668547b5c8fb316c507a9a9 (diff)
rename base SRTool directories, update README files
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Diffstat (limited to 'TODO')
1 files changed, 1 insertions, 61 deletions
diff --git a/TODO b/TODO
index 54d091fb..b10262af 100644
--- a/TODO
+++ b/TODO
@@ -1,62 +1,2 @@
-- Reimplement the interactive mode as a proper ui
-- Continue dropping fatal/SystemExit/sys.exit usage in favor of raising
- appropriate exceptions
-- Continue pylint / pyflakes / pychecker / pep8 fixups
-- Drop os.system usage in favor of direct subprocess usage or a subprocess
- wrapper
-- Kill the execution of 'tee' for the task log file in build.py
-- Fix up the exception handling
- - Kill exec_task's catch of FuncFailed, instead catch it in the other
- callers of exec_task/exec_func
- - What exactly is the purpose of the "EventException"? I can see using an
- exception like that, *perhaps*, to abstract away exceptions raised by
- event handlers, but it has no place in bb.build.exec_task
-- 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
- exceptions
-- 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:
- - Change override application to actually *move* it over -- so the original
- override specific version of the variable goes away, rather than sticking
- around as a duplicate.
- - Change the behavior when a variable is referenced and is unset. Today, it
- evaluates to ${FOO} and then shell has a chance to expand it, but this is
- far from ideal. We had considered evaluating it to the empty string, but
- that has other potential problems. Frans Meulenbroeks has proposed just
- erroring when this occurs, as we can always define default values for the
- variables in bitbake.conf. This seems reasonable. My only concern with
- that is the case where you want to reference a shell variable with odd
- characters in it -- where you'd have to use ${} style shell variable
- expansion rather than normal $. To handle that case, we'd really need a
- way to escape / disable bitbake variable expansion, \${} perhaps.
- - Leverage the python 2.6 multiprocessing module
- - Worker processes for bb.cooker
- - Server / UI processes
- - Create a bitbake configuration class which is utilized by the library, not
- just bin/bitbake. This class should be responsible for extracting
- configuration parameters from the metadata for bitbake internal use, as well
- as pulling specific items like BBDEBUG, and importing settings from an
- optparse options object.
- - Python version bits
- - Utilize the new string formatting where appropriate
- - Do we need to take into account the bytes literals changes?
- - Do we have any file-like objects that would benefit from using the "io"
- module?
- - Do we want to leverage the abstract base classes in collections?
- - Aside: Set methods now accept multiple iterables
+Todo for SRTool