aboutsummaryrefslogtreecommitdiffstats
path: root/meta/classes
diff options
context:
space:
mode:
authorPaul Eggleton <paul.eggleton@linux.intel.com>2016-08-09 09:06:53 +1200
committerPaul Eggleton <paul.eggleton@linux.intel.com>2016-08-11 16:40:45 +1200
commit303d3026c3bd97ad624ef6add479c67af6cb9213 (patch)
treea2402b20f33472f0af623d4fb9f65073fd868685 /meta/classes
parent2d8113d1c3f515bf0959bc15adfaf6f316efd20b (diff)
downloadopenembedded-core-contrib-303d3026c3bd97ad624ef6add479c67af6cb9213.tar.gz
lib/oe/copy_buildsystem: fix merging sstate directories for eSDK
When we don't have uninative enabled there's more merging to be done in the default configuration (SDK_EXT_TYPE = "full" which by default means SDK_INCLUDE_TOOLCHAIN = "1") and there are likely files that already exist in the sstate feed we're assembling, so we need to take care to merge the directory contents rather than just moving the directories over. Additionally we now only run this if uninative genuinely isn't enabled (i.e. NATIVELSBSTRING is different to the fixed value of "universal".) In the process of fixing this I discovered an unusual behaviour in os.rename() - when we're merging these feeds we're dealing with hard-linked sstate artifacts, and whilst os.rename() is supposed to silently overwrite an existing destination (permissions allowing), if you have the source and destination as hardlinks to the same file then the os.rename() call will just silently fail. As a result the code now just checks if the destination exists and deletes the source if so (since we know it will be the same file, we don't need to check in this case.) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Diffstat (limited to 'meta/classes')
0 files changed, 0 insertions, 0 deletions