|
@@ -32,6 +32,22 @@
|
|
|
Looks like we may be able to use removeHandler.. will have to see how it
|
|
|
interacts with parent/child loggers.
|
|
|
|
|
|
+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
|