1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162 |
- - 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.
- Uncertain:
- - 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
|