summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/data.py
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2015-05-27 17:37:33 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-05-29 10:17:16 +0100
commitb8caddb57ae3a4d0affd54a6d43bb9eace556921 (patch)
treed6015f591a5eef7fe254e6f35216d0a92b84d298 /bitbake/lib/bb/data.py
parent3db9d6e02d6ebfcce0e83f7875f5dc1f6bdce157 (diff)
downloadpoky-b8caddb57ae3a4d0affd54a6d43bb9eace556921.tar.gz
bitbake: data: Make expandKeys deterministic
At least in theory, the order the keys are expanded in can make a difference, particularly if there is key overlap. We also want to ensure that any underlying base key is processed before any overridden version of that variable (FOO before FOO_x) which helps the update_data removal code I've been testing. (Bitbake rev: 863b6add24c211d64ba7931647084321f2d65889) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/data.py')
-rw-r--r--bitbake/lib/bb/data.py2
1 files changed, 1 insertions, 1 deletions
diff --git a/bitbake/lib/bb/data.py b/bitbake/lib/bb/data.py
index 439c36593d..84f5355e42 100644
--- a/bitbake/lib/bb/data.py
+++ b/bitbake/lib/bb/data.py
@@ -159,7 +159,7 @@ def expandKeys(alterdata, readdata = None):
159 159
160 # These two for loops are split for performance to maximise the 160 # These two for loops are split for performance to maximise the
161 # usefulness of the expand cache 161 # usefulness of the expand cache
162 for key in todolist: 162 for key in sorted(todolist):
163 ekey = todolist[key] 163 ekey = todolist[key]
164 newval = alterdata.getVar(ekey, 0) 164 newval = alterdata.getVar(ekey, 0)
165 if newval is not None: 165 if newval is not None: