TODO 3.4 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071
  1. - Reimplement the interactive mode as a proper ui
  2. - Move the LAYERDIR expansion hack into DataSmart, as that's where code that
  3. depends upon its internals belongs
  4. - Continue dropping fatal/SystemExit/sys.exit usage in favor of raising
  5. appropriate exceptions
  6. - Continue pylint / pyflakes / pychecker / pep8 fixups
  7. - Drop os.system usage in favor of direct subprocess usage or a subprocess
  8. wrapper
  9. - Kill the execution of 'tee' for the task log file in build.py
  10. - Fix up the exception handling
  11. - Kill exec_task's catch of FuncFailed, instead catch it in the other
  12. callers of exec_task/exec_func
  13. - What exactly is the purpose of the "EventException"? I can see using an
  14. exception like that, *perhaps*, to abstract away exceptions raised by
  15. event handlers, but it has no place in bb.build.exec_task
  16. - Leverage the python logging module
  17. - Create a new logging Handler which instantiates MsgBase derived objects
  18. and passes them along, either via bb.event or directly over the
  19. appropriate queues to the other processes.
  20. - Alter the bb.msg functions to use the logging module.
  21. - Convert bb modules to stop using the bb.msg functions.
  22. - Switch the messaging wrappers in the bb package to use the logging module
  23. directly, as we'll be deprecating the bb.msg versions, but these should
  24. stay around for the metadata to use.
  25. - Deprecate the bb.msg functions.
  26. - Do we want to use the logging module in any of the UIs, for local
  27. messages, as well? If we do, we don't want those to use our handler which
  28. sends the Msg events to the UI :)
  29. Looks like we may be able to use removeHandler.. will have to see how it
  30. interacts with parent/child loggers.
  31. Long term, high impact:
  32. - Change override application to actually *move* it over -- so the original
  33. override specific version of the variable goes away, rather than sticking
  34. around as a duplicate.
  35. - Change the behavior when a variable is referenced and is unset. Today, it
  36. evaluates to ${FOO} and then shell has a chance to expand it, but this is
  37. far from ideal. We had considered evaluating it to the empty string, but
  38. that has other potential problems. Frans Meulenbroeks has proposed just
  39. erroring when this occurs, as we can always define default values for the
  40. variables in bitbake.conf. This seems reasonable. My only concern with
  41. that is the case where you want to reference a shell variable with odd
  42. characters in it -- where you'd have to use ${} style shell variable
  43. expansion rather than normal $. To handle that case, we'd really need a
  44. way to escape / disable bitbake variable expansion, \${} perhaps.
  45. Uncertain:
  46. - Leverage the python 2.6 multiprocessing module
  47. - Worker processes for bb.cooker
  48. - Server / UI processes
  49. - Create a bitbake configuration class which is utilized by the library, not
  50. just bin/bitbake. This class should be responsible for extracting
  51. configuration parameters from the metadata for bitbake internal use, as well
  52. as pulling specific items like BBDEBUG, and importing settings from an
  53. optparse options object.
  54. - Python version bits
  55. - Utilize the new string formatting where appropriate
  56. - Do we need to take into account the bytes literals changes?
  57. - Do we have any file-like objects that would benefit from using the "io"
  58. module?
  59. - Do we want to leverage the abstract base classes in collections?
  60. - Aside: Set methods now accept multiple iterables