diff options
author | Richard Purdie <rpurdie@linux.intel.com> | 2010-12-06 00:39:20 +0000 |
---|---|---|
committer | Richard Purdie <rpurdie@linux.intel.com> | 2010-12-07 12:16:16 +0000 |
commit | c354955d26d34316b3dbf0e2175526838401f3b6 (patch) | |
tree | ac7e287b4d3610abb2f73b36cebb4e899734b5d9 /meta/site/common-glibc | |
parent | 9d0d2b044edf8bf2ffaec6f2423b5d7bddb528f2 (diff) | |
download | openembedded-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/common-glibc')
0 files changed, 0 insertions, 0 deletions