summaryrefslogtreecommitdiff
path: root/meta/site/x86_64-linux
diff options
context:
space:
mode:
authorRichard Purdie <rpurdie@linux.intel.com>2010-12-06 00:39:20 +0000
committerRichard Purdie <rpurdie@linux.intel.com>2010-12-07 12:16:16 +0000
commitc354955d26d34316b3dbf0e2175526838401f3b6 (patch)
treeac7e287b4d3610abb2f73b36cebb4e899734b5d9 /meta/site/x86_64-linux
parent9d0d2b044edf8bf2ffaec6f2423b5d7bddb528f2 (diff)
downloadopenembedded-core-c354955d26d34316b3dbf0e2175526838401f3b6.tar.gz
openembedded-core-c354955d26d34316b3dbf0e2175526838401f3b6.tar.bz2
openembedded-core-c354955d26d34316b3dbf0e2175526838401f3b6.tar.xz
openembedded-core-c354955d26d34316b3dbf0e2175526838401f3b6.zip
bitbake/data_smart: Fix append/prepend/override ordering issue
Where a variable name consisted of an append/prepend combined with an override and there was also an append/prepend to the variable, the override could be lost if the override was not in OVERRIDES. For example: FOO = "A" FOO_append = "B" FOO_append_virtclass-native = "C" could result in "AB" even though virtclass-native was in OVERRIDES. With this patch applied, the result is "ABC" as would be expected. The problem was the deletion of the _append/_prepend flag was happening if *any* append/prepend was procesed, the result should really be that it should contain any unprocessed append/prepend. Kevin Tian deserves credit for looking into this and working out the problem here. Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Diffstat (limited to 'meta/site/x86_64-linux')
0 files changed, 0 insertions, 0 deletions