diff options
author | Christopher Larson <chris_larson@mentor.com> | 2011-10-28 23:06:18 -0400 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-11-10 11:44:29 +0000 |
commit | 7e436a98454275bea71cb511d13ad3665a1caba9 (patch) | |
tree | b6d7b1576a8d8010353c7f5041d77283e0d348d0 /bitbake/lib/bb/daemonize.py | |
parent | ae96ac11897c1017aea359a8e3325291bc198293 (diff) | |
download | poky-7e436a98454275bea71cb511d13ad3665a1caba9.tar.gz |
codeparser: drop expand tracking
There are two usual cases involving bb.data.expand:
- Calling it with a string literal -- "bb.data.expand('${FOO}/${BAZ}/bleh', d)".
- Calling it on getVar results (legacy) -- "bb.data.expand(bb.data.getVar('FOO', d), d)"
Nothing in any of the usual layers uses it in any other way, and I'm
having trouble coming up with any real use cases beyond this. The first
of the above cases is already tracked, via the expandWithRefs called
on the python code string. The second didn't emit a warning anyway,
since the getVar was already handled.
Given this, I see no reason for us to maintain explicit expansion
tracking. Further, we weren't using its results anyway (the var_expands
member).
(Bitbake rev: 405dfe69e6a608826e599ebf2f83ef8cf5083b96)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/daemonize.py')
0 files changed, 0 insertions, 0 deletions