summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/utils.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>2012-01-30 16:16:13 +0000
commitc61f04c34ef581d50dbb6e011ca7460308ed284d (patch)
tree0051dee97aaa0cec7433949c04e6a3d853c7fc7b /bitbake/lib/bb/utils.py
parent2b26745c70a01bbabf5a303fe12a8b3b41071890 (diff)
downloadpoky-c61f04c34ef581d50dbb6e011ca7460308ed284d.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/utils.py')
0 files changed, 0 insertions, 0 deletions