summaryrefslogtreecommitdiffstats
path: root/meta/files/ext-sdk-prepare.py
Commit message (Collapse)AuthorAgeFilesLines
* classes/populate_sdk_ext: drop duplicated error messagePaul Eggleton2016-08-171-1/+1
| | | | | | | | | | | | | | | | The preparation script itself prints out an error on failure, and we aren't redirecting its output anymore, so we no longer need to print out a message here when it fails. At the same time, make the message printed out by the script a little clearer - we're just writing the log out to the file, we shouldn't give the user an expectation that there will be extra details in there (other than the output produced by oe-init-build-env there won't be). (From OE-Core rev: 80dfaf40e087b34d6360188df372c1c3805a00bd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: show progress when preparing build systemPaul Eggleton2016-07-261-24/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]. (From OE-Core rev: 0f7cb880c934b7871f3b8432f4f02603300f6129) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: eliminate double execution on installPaul Eggleton2016-07-081-51/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]. (From OE-Core rev: e1390c1ef85862b91b067ab24f3c06ca506155ad) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: Replace basestring -> str for python3Ed Bartosh2016-06-021-1/+1
| | | | | | | | | | Python 3 doesn't have basestring type as all string are unicode strings. (From OE-Core rev: e8cfab060f4ff3c4c16387871354d407910e87aa) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ext-sdk-prepare.py: exclude do_rm_work from unexpected output; create unit testBill Randle2016-04-181-11/+16
| | | | | | | | | | | | | | | | | When installing the esdk with INHERIT += "rm_work", the script complains about do_rm_work as unexpected output from the bitbake run. This patch ignores any output lines with do_rm_work and further refactors the output comparison into its own function creates a new unit test to verify the fix. The unit test can be run direct from the command line or via oe-selftest. [YOCTO #9019] (From OE-Core rev: d41930e1daa933cf4bf063fa79a2e8fc9129e1b1) Signed-off-by: Bill Randle <william.c.randle@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts, lib: Don't limit traceback lengths to arbitrary valuesRichard Purdie2016-03-311-1/+1
| | | | | | | | | | | | | | | | There appears to have been a lot of copy and pasting of the code which prints tracebacks upon failure and limits the stack trace to 5 entries. This obscures the real error and is very confusing to the user it look me an age to work out why some tracebacks weren't useful. This patch removes the limit, making tracebacks much more useful for debugging. [YOCTO #9230] (From OE-Core rev: 6069175e9bb97ace100bb5e99b6104d33163a3a2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: parse metadata on minimal SDK installPaul Eggleton2016-03-251-3/+7
| | | | | | | | | | | | Instead of skipping the build system preparation step within the extensible SDK install process when SDK_EXT_TYPE is "minimal", run bitbake -p so that the cache is populated ready for the first time devtool is run. (From OE-Core rev: 6b38a991a3475fb82889428b94563968c7570473) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ext-sdk-prepare: Catch setscene tasks which should have run but didn'tRichard Purdie2016-03-071-1/+3
| | | | | | | | | | | | When installing the eSDK, if setscene task fail for some reason, the tests would ignore this. This is bad since we assume they're working. This adds some sanity test code which detects if setscene tasks are needing to run and errors if there are any. (From OE-Core rev: 7ea670c3b00439ca5eeb6ae1efd475f0954268b7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: check that extensible SDK prepared correctlyPaul Eggleton2016-01-151-0/+92
After the change to use --setscene-only when running bitbake to prepare the SDK at the end of installation, add a check that the SDK got prepared correctly by doing a dry-run and looking at the output for any real tasks that we don't expect. In order to make this easier, the preparation shell script was rewritten in python. (From OE-Core rev: 2306683634435b990e63020fc5cf91753bbaf7b6) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>