63 lines
2.8 KiB
Plaintext
63 lines
2.8 KiB
Plaintext
- 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
|
|
|