diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 62 |
1 files changed, 1 insertions, 61 deletions
@@ -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. - -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 +Todo for SRTool |