openembedded-core.git/meta/classes/populate_sdk_ext.bbclass, branch uninative-1.3

classes/populate_sdk_ext: add gdb to full extensible SDK

2016-07-25T22:47:02+00:00

If SDK_EXT_TYPE is set to "full" then we really ought to be shipping
everything that is expected to be in the SDK, and that includes gdb
(it's already referred to by the environment setup script if nothing
else). This is implemented by using the SDK_INCLUDE_TOOLCHAIN
functionality I just added, since the only material thing that adds on
top of a full SDK is gdb and we should always have the rest of it in a
full SDK anyway.

Fixes [YOCTO #9850].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/populate_sdk_ext: filter sstate within the extensible SDK

2016-07-25T22:47:02+00:00

Use the new oe-check-sstate to filter the sstate artifacts shipped with
the extensible SDK by effectively running bitbake within the produced
eSDK and and getting it to tell us which tasks it will restore from
sstate. This has several benefits:

1) We drop the *-initial artifacts from the minimal + toolchain eSDK.
   This still leaves us with a reasonably large SDK for this
   configuration, however it does pave the way for future reductions
   since we are actually filtering by what will be expected to be there
   on install rather than hoping that whatever cuts we make will match.

2) We verify bitbake's basic operation within the eSDK, i.e. that
   we haven't messed up the configuration

3) We verify that the sstate artifacts we expect to be present are
   present (at least in the sstate cache for the build producing the
   eSDK). Outside deletion of sstate artifacts has been a problem up to
   now, and this should at least catch that earlier i.e. during the
   build rather than when someone tries to install the eSDK.

This does add a couple of minutes to the do_populate_sdk_ext time, but
it seems like the most appropriate way to handle this.

Should mostly address [YOCTO #9083] and [YOCTO #9626].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/populate_sdk_ext: allow including toolchain in eSDK on install

2016-07-25T22:47:02+00:00

If we're to completely replace the standard SDK with the extensible SDK,
we need to be able to provide the standard toolchain on install without
doing anything other than installing it, so that you can install the SDK
and then point your IDE at it. This is particularly applicable to the
minimal SDK which normally installs nothing by default.

NOTE: enabling this option currently adds ~280MB to the size of the
minimal eSDK installer. If we need to reduce this further we would have
to look at adjusting the dependencies and/or the sstate_depvalid()
function in sstate.bbclass which eliminates dependencies, or look at
reducing the size of the artifacts themselves.

Implements [YOCTO #9751].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/populate_sdk_ext: set default for SDK_INCLUDE_PKGDATA

2016-07-25T22:47:02+00:00

We don't absolutely need this - it doesn't change the default
behaviour, but it seems to me we have a convention to set default values
so we should add one here.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/populate_sdk_ext: show progress when preparing build system

2016-07-25T22:46:58+00:00

During the extensible SDK installation process the final step is to
prepare the internal copy of the build system. This can take some time,
especially if you have SDK_EXT_TYPE set to "minimal" (downloading
sstate artifacts) and SDK_INCLUDE_PKGDATA set to "1" (restoring
pkgdata for world). To make this a bit less painful, use BitBake's new
quiet mode to display status during this operation so you have some idea
of how it's progressing; instead of redirecting the output to
preparing_build_system.log we grab the last console log and append it
instead.

One result of this change is that you get the errors printed on the
console during normal output rather than this going to the
preparing_build_system.log file first. In OE-Core revision
227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the
contents of preparing_build_system.log on failure, but now at least the
error contents of that log is duplicated. Besides, I intentionally
didn't print out the contents of that log during normal usage because
it's quite verbose - the bug that we were attempting to fix was about
not getting this information when seeing failures in the automated
tests, thus I've moved printing the log to the test handling code
instead.

Part of the implementation for [YOCTO #9613].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: exclude initramfs images from locked signatures

2016-07-08T08:55:40+00:00

Tasks for image recipes cannot be locked - there's nothing to restore
from shared state to cover them and as a result, if you had "live" in
IMAGE_FSTYPES the build would fail with "taskhash mismatch" errors for
do_rootfs and do_image_complete for the initramfs image recipe, since it
had to try to run those. We should probably catch that issue earlier in
the build and produce a proper error, but for now at least exclude these
signatures from the locked-sigs.inc file so that extensible SDK
installers built when IMAGE_FSTYPES includes "live". (It turned out we
already had code to find other image tasks in the task list in order to
generate the list of install targets.)

Follow-up fix for [YOCTO #9826].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: ensure tasks to build the image are included

2016-07-08T08:55:40+00:00

If you build an extensible SDK for an image and IMAGE_FSTYPES includes
"live" then the extensible SDK will fail to install with a bunch of
unexpected task execution errors, matching the missing items required to
build the live image. The issue was we were still depending on do_rootfs
rather than do_image_complete. The fix was slightly more complicated
than just changing the task name as do_image_complete's dependencies are
in the form of dependencies on tasks within the same recipe (represented
in the "deps" varflag rather than the "depends" varflag).

Fixes [YOCTO #9826].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/populate_sdk_ext: eliminate double execution on install

2016-07-07T12:29:01+00:00

Use the new BB_SETSCENE_ENFORCE functionality to avoid having to run
bitbake twice on installing the extensible SDK - we can now do it all in
one invocation which not only takes less time, but we should also get
more meaningful errors for some types of failure, in particular where
downloading from an sstate mirror fails.

One result of this change is that you get the errors printed on the
console during normal output rather than this going to the
preparing_build_system.log file first. In OE-Core revision
227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the
contents of preparing_build_system.log on failure, but now at least the
error contents of that log is duplicated. Besides, I intentionally
didn't print out the contents of that log during normal usage because
it's quite verbose - the bug that we were attempting to fix was about
not getting this information when seeing failures in the automated
tests, thus I've moved printing the log to the test handling code
instead.

Part of the implementation of [YOCTO #9367].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/lib: Complete transition to python3

2016-06-02T07:10:04+00:00

This patch contains all the other misc pieces of the transition to
python3 which didn't make sense to be broken into individual patches.

Signed-off-by: Richard Purdie

classes/lib: Update to match python3 iter requirements

2016-06-02T07:10:02+00:00

python3 standardises its use of iteration operations. Update
the code to match the for python3 requires.

Signed-off-by: Richard Purdie