linux/poky.git/meta/classes/populate_sdk_ext.bbclass, branch yocto-2.4

devtool: ensure recipes devtool is working on are unlocked within the eSDK

2017-09-18T10:07:29+00:00

Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

populate_sdk_ext: Add BB_SERVER_TIMEOUT to SDK_LOCAL_CONF_BLACKLIST

2017-08-24T12:48:10+00:00

Whilst this should work we see failures in testsdkext at the moment when this is set. Add this to the blacklist for now until we can fix these issues meaning we can at least test BB_SERVER_TIMEOUT in other scenarios. Bug 119733 has been opened to track this. (From OE-Core rev: 88cb174680cd37b5afb2b79e8248979895c35312) Signed-off-by: Richard Purdie

populate_sdk_ext: Add variable to indicate running in eSDK

2017-07-21T21:51:37+00:00

This allows for other scripts to know that they are being executed in the context of the eSDK in order to provide different behaviour as needed. [YOCTO #11155] (From OE-Core rev: ebdd9b5a19eb6fb6c3249be4f0e2480a3de2aa8f) Signed-off-by: Saul Wold Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe-init-build-env-memres: Drop it

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

With the new server structure we no longer need this separate environment init script. Just set BB_SERVER_TIMEOUT to be greater than zero and bitbake will remain in memory and the UI will auto-reconnect to it. Also clean out the old shutdown code from oe-init-build-env which also doesn't make sense now. (From OE-Core rev: a17724d687f9c04dc21f2f369da2b492f7119ba0) Signed-off-by: Richard Purdie

meta/classes/populate_sdk: Adds support for generating eSDK manifest files

2017-06-12T22:01:23+00:00

Add get_extra_sdk_info to reuse code in buildhistory The functionalities to generate SDK and eSDK manifest files are different, the SDK comes from package information and the eSDK comes from sstate artifacts. Only execute write_sdk_{host, target}_manifest when is on populate_sdk class. Adds new functions write_sdk{host, target}_ext_manifest to execute on postprocess in populate_sdk_ext because at the end we have all the sstate artifacts to generate the manifest. [YOCTO #9038] (From OE-Core rev: 25ad7ed6f7bb0c931b404bda09576323200d093d) Signed-off-by: Francisco Pedraza Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie

populate_sdk_ext: Avoid build failures where sstate was used

2017-05-16T13:08:28+00:00

If sstate was used to populate the build and one of the universal-4.8 or universal-4.9 mirror urls was used, the sstate checks during eSDK construction could fail as it would zero out the SSTATE_MIRRORs variable. Use the same mirrors variable setting as the eSDK would end up using to perform the checks to avoid this. (From OE-Core rev: 6b9e8b780dcd8d5ffba3df35cfe41674413ee26d) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: work around runqemu behaviour within the eSDK

2017-04-19T09:38:37+00:00

Currently, in order to figure out variable values when run within the eSDK, runqemu does not use the standard SDK method nor is it able to run bitbake (since the eSDK environment isn't initialised like the normal OE build environment). runqemu really ought to be fixed, but the quick workaround is to set DEPLOY_DIR_IMAGE in the environment so that runqemu can find image files. Fixes [YOCTO #10447]. (From OE-Core rev: 1ef833b6393366a10f4bb65df89725ad65761386) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

populate_sdk_ext: Add do_addto_recipe_sysroot to BB_SETSCENE_ENFORCE_WHITELIST

2017-04-14T08:47:09+00:00

Without this, eSDK builds are failing due to qemu-helper-native's dependency on this task. It makes sense to allow this to execute in eSDK contexts (its a non-sstate task intentionally). (From OE-Core rev: 3e8ade8c0772c4492efd93824f78cb043281d235) Signed-off-by: Richard Purdie

classes/populate_sdk_ext: reset TCLIBCAPPEND to get consistent TMPDIR

2017-04-14T08:47:08+00:00

populate_sdk_ext sets TMPDIR to a known static value with '/tmp' directory name and that name is hard coded in a few places (e.g., in meta-environment-extsdk.bb that writes the eSDK environment variables). Distros that do not reset TCLIBCAPPEND (poky does) end up getting TMPDIR = /tmp-${TCLIBCAPPEND} via defaultsetup.conf and that breaks the functionality in eSDK that expects everything is in /tmp. To get TMPDIR consistent, we also need to reset TCLIBCAPPEND in populate_sdk_ext.bbclass. Fixes: [YOCTO #11298] (From OE-Core rev: 9ec29153f279bb9e1dbcddc2c66e00fdbe3fd6e9) Signed-off-by: Mikko Ylinen Signed-off-by: Richard Purdie

populate_sdk_ext.bbclass: enhance compatibility with rm_work.bbclass

2017-03-31T09:10:29+00:00

"bitbake -c populate_dsk_ext" must not trigger do_rm_work, because it is impossible to declare that the additional tasks activated by "-c populate_dsk_ext" must run before do_rm_work. When do_populate_dsk_ext and do_rm_work are both active, the resulting race condition breaks do_populate_dsk_ext. The existing bitbake dependencies can't be used for that, because "addtask populate_dsk_ext before do_rm_work" would then always execute populate_dsk_ext also in normal builds. do_populate_dsk_ext triggers do_rm_work indirectly through the dependency on do_build of the SDK_TARGETs. Using the new do_build_without_rm_work instead (when available, with do_build as before if not) avoids the problem. However, one has to be careful to not trigger do_rm_work in the same build in some other way. "bitbake core-image-sato:do_populate_sdk_ext core-image-sato:do_build" still fails, for example. Doing one after the other works. Fixes: [YOCTO 11042] (From OE-Core rev: 00b1911c65fa1b21c3dedec40170998573b62178) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie