summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/data.py
diff options
context:
space:
mode:
authorChristopher Larson <chris_larson@mentor.com>2011-10-28 23:06:18 -0400
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-11-10 11:44:29 +0000
commit7e436a98454275bea71cb511d13ad3665a1caba9 (patch)
treeb6d7b1576a8d8010353c7f5041d77283e0d348d0 /bitbake/lib/bb/data.py
parentae96ac11897c1017aea359a8e3325291bc198293 (diff)
downloadpoky-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/data.py')
0 files changed, 0 insertions, 0 deletions