aboutsummaryrefslogtreecommitdiffstats
path: root/meta/recipes-multimedia
diff options
context:
space:
mode:
authorPaul Eggleton <paul.eggleton@linux.intel.com>2016-08-11 16:45:02 +1200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2016-08-17 10:32:04 +0100
commit2b5b920c6b4f4d5c243192aa75beff402fd704d3 (patch)
tree058c8f62b21fa946551f36f06765e5baafbe701c /meta/recipes-multimedia
parent71ecd3bea680ef8c589257844512a14b65e979d3 (diff)
downloadopenembedded-core-contrib-2b5b920c6b4f4d5c243192aa75beff402fd704d3.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> Signed-off-by: Ross Burton <ross.burton@intel.com>
Diffstat (limited to 'meta/recipes-multimedia')
0 files changed, 0 insertions, 0 deletions