linux/poky.git/meta/lib/oe/copy_buildsystem.py, branch 2.7_M2

oe/copy_buildsystem.py: add SDK_LAYERS_EXCLUDE_PATTERN

2018-07-09T21:48:38+00:00

It is helpful when exclude a lot of layers. It uses python re, and supports multiple patterns (separated by space). (From OE-Core rev: b5170882feb0f3bc2dddc213b6d115dfa87b7cc1) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

populate_sdk_ext.bbclass: fix corebase identification

2018-06-18T10:07:57+00:00

When generating the extended SDK, there is a copy step where this class goes through the layers and other stuff that have been copied to generate the SDK. The corebase; ie. the folder that contains the core layer 'meta' is treated in a special way. Unfortunately in our tree, we have: sources/meta/meta | `- core layer `------- corebase In populate_sdk_ext's copy_buildsystem, the heuristic to determine which element of the list returned by copy_bitbake_and_layers is corebase is fooled by such layout. In copy_bitbake_and_layers, corebase is already handled specifically and reliably, so we should let that function tell us which folder is corebase instead of trying to determine it. To do so, change the return type of copy_bitbake_and_layers to a tuple that contains (corebase, copied_layers). It also simplifies the code on the caller side. (From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1) Signed-off-by: Damien Riegel Signed-off-by: Richard Purdie

oe/copy_buildsystem.py: make sure layer exists

2018-01-06T22:32:22+00:00

It had a problem when nested layer before, e.g.: layer_a/layer_b/ And when layer_b is handled before layer_a, then layer_a dir existed, so it would be treated as already handled, which was wrong, check conf/layer.conf can fix the problem. (From OE-Core rev: 2eaefa0c3ae589111266c7d6822428ad910415f4) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

devtool/copy_buildsystem: adds meta-skeleton layer in the eSDK installation.

2017-08-19T21:15:39+00:00

The eSDK installation requires the meta-skeleton layer. The build system might use the meta-skeleton recipes as layout to create custom recipes. An example is the recipetool script that uses the meta-skeleton kernel recipe when creating a custom kernel recipe. [YOCTO #11102] (From OE-Core rev: 5c9ef0734d23909b5694ed43cdbb205c2ba9ca95) Signed-off-by: Juan M Cruz Alcaraz Signed-off-by: Richard Purdie

copy_buildsystem: include layer tree during build structure creation

2017-08-18T22:46:37+00:00

When buildsystem with layer structure is going to be copied, only the last meta-XXX layer is taken. For example, during ext_sdk bblayers creating: layers/oe/meta \ layers/oe/meta-oe \ layers/oe/meta-networking \ layers/oe/meta-webserver \ ... It restructured meta-oe, meta-networking,... contents into meta-oe. Recipes from meta-oe will be on the same level like meta-networking, meta-webserver, ... . It should take the whole meta path instead of the last one. layers/oe/meta \ layers/oe/meta-oe/meta-oe \ layers/oe/meta-oe/meta-networking \ layers/oe/meta-oe/meta-webserver \ ... Now the directory structure is the same like during build creation. (From OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b) Signed-off-by: Andrej Valek Signed-off-by: Pascal Bach Signed-off-by: Richard Purdie

oe/copy_buildsystem: check_sstate_task_list also pop BBPATH from env

2017-07-21T07:44:25+00:00

The BBPATH environment could be set and can make a failure when try to build an extensible sdk because it will look the bitbake.lock file in the original build folder. Example: $ export BBPATH=`pwd` $ bitbake core-image-minimal -c populate_sdk_ext ERROR: bitbake failed: ERROR: Only one copy of bitbake should be run against a build directory ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: copy_buildsystem (From OE-Core rev: 33634b4c38d84e1c5d06056766933f1fe4f47e8d) Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?$( ?[^,()]*), True$ (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe/copy_buildsystem.py: dereference symlink

2016-11-06T23:35:32+00:00

When there is a relative symlink in the layer, for example: symA -> ../out/of/layer/file symA will be invalid fater copied, it would be invalid from build time if it points to a relative path, and would be invalid after extracted the sdk if it points to a absolute py. Dereference symlink when copy will fix the problem. Use tar rather than shutil.copytree() to copy is because: 1) shutil.copytree(symlinks=Fasle) has bugs when dereference symlinks: https://bugs.python.org/issue21697 And Ubunutu 1404 doesn't upgrade python3 to fix the problem. 2) shutil.copytree(symlinks=False) raises errors when there is a invalid symlink, and tar just prints a warning, tar is preferred here since the real world is unpredicatable 3) tar is faster than shutil.copytree() as said by oe.path.copytree() So use tar to copy. (From OE-Core rev: f4d70bb0882eec4fb46cd942f2796fad57c72982) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

lib/oe/copy_buildsystem: fix building eSDK with indirect paths in BBLAYERS

2016-09-14T21:22:13+00:00

Indirect paths (e.g. ${TOPDIR}/../meta-something) do generally work if used in BBLAYERS in bblayers.conf. However, if you built an extensible SDK with this configuration then the creation of the workspace within the SDK using devtool in do_populate_sdk_ext failed. This is because the copy_buildsystem code was no longer correctly recognising that the core layer ("meta") was part of a repository (e.g. openembedded-core / poky) that should be shipped together - because of the indirection - and thus it was splitting out the meta directory, and a number of places in the code assume that the meta directory is next to the scripts directory. Use os.path.abspath() to flatten out any indirections. (From OE-Core rev: 7c0788cd2390fd0e1ec84bc9dbebcb67daee429f) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

lib/oe/copy_buildsystem: fix merging sstate directories for eSDK

2016-08-17T09:35:40+00:00

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.) (From OE-Core rev: 2b5b920c6b4f4d5c243192aa75beff402fd704d3) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie