TODO 2.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162
  1. - Reimplement the interactive mode as a proper ui
  2. - Continue dropping fatal/SystemExit/sys.exit usage in favor of raising
  3. appropriate exceptions
  4. - Continue pylint / pyflakes / pychecker / pep8 fixups
  5. - Drop os.system usage in favor of direct subprocess usage or a subprocess
  6. wrapper
  7. - Kill the execution of 'tee' for the task log file in build.py
  8. - Fix up the exception handling
  9. - Kill exec_task's catch of FuncFailed, instead catch it in the other
  10. callers of exec_task/exec_func
  11. - What exactly is the purpose of the "EventException"? I can see using an
  12. exception like that, *perhaps*, to abstract away exceptions raised by
  13. event handlers, but it has no place in bb.build.exec_task
  14. - BUG: if you chmod 000 local.conf, it silently doesn't parse it, when it
  15. should really fail, so the user can fix the problem.
  16. - Audit bb.fatal usage - these should all be able to be replaced with
  17. exceptions
  18. - Figure out how to handle the ncurses UI. Should some of our logging
  19. formatting stuff be made common to all of bitbake, or perhaps all UIs via
  20. the UIHelper?
  21. Long term, high impact:
  22. - Change override application to actually *move* it over -- so the original
  23. override specific version of the variable goes away, rather than sticking
  24. around as a duplicate.
  25. - Change the behavior when a variable is referenced and is unset. Today, it
  26. evaluates to ${FOO} and then shell has a chance to expand it, but this is
  27. far from ideal. We had considered evaluating it to the empty string, but
  28. that has other potential problems. Frans Meulenbroeks has proposed just
  29. erroring when this occurs, as we can always define default values for the
  30. variables in bitbake.conf. This seems reasonable. My only concern with
  31. that is the case where you want to reference a shell variable with odd
  32. characters in it -- where you'd have to use ${} style shell variable
  33. expansion rather than normal $. To handle that case, we'd really need a
  34. way to escape / disable bitbake variable expansion, \${} perhaps.
  35. Uncertain:
  36. - Leverage the python 2.6 multiprocessing module
  37. - Worker processes for bb.cooker
  38. - Server / UI processes
  39. - Create a bitbake configuration class which is utilized by the library, not
  40. just bin/bitbake. This class should be responsible for extracting
  41. configuration parameters from the metadata for bitbake internal use, as well
  42. as pulling specific items like BBDEBUG, and importing settings from an
  43. optparse options object.
  44. - Python version bits
  45. - Utilize the new string formatting where appropriate
  46. - Do we need to take into account the bytes literals changes?
  47. - Do we have any file-like objects that would benefit from using the "io"
  48. module?
  49. - Do we want to leverage the abstract base classes in collections?
  50. - Aside: Set methods now accept multiple iterables