aboutsummaryrefslogtreecommitdiffstats
path: root/meta/classes/populate_sdk_ext.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* populate_sdk_ext.bbclass: check unfsd before create itRobert Yang2016-11-151-2/+3
| | | | | | | | | | | | Fixed when nativesdk-unfs3 is installed: $ bitbake <image> -c populate_sdk_ext | Traceback (most recent call last): | File "/path/to/oe-core/scripts/lnr", line 21, in <module> | os.symlink(target, linkname) | FileExistsError: [Errno 17] File exists: '../../../../tmp/sysroots/x86_64-linux/usr/bin/unfsd' -> '/path/to/9.0/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/unfsd' Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: require uninativePaul Eggleton2016-11-061-4/+3
| | | | | | | | | | | | | | | | It seems that possibly due to OE-Core commit ac59063bee0e32d0737340974f657341717a6abe, binaries produced without uninative aren't compatible with the uninative glibc. I did try earlier to ensure that the eSDK could work without uninative since the default configuration in OE-Core does not enable it, but it seems like I didn't go far enough. Given the practical considerations, just give up and require uninative to be enabled in order to build the eSDK. I'm not particularly happy about this, but I don't seem much of an alternative. Fixes [YOCTO #10566]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: prevent invalid TEMPLATECONF entering eSDKPaul Eggleton2016-11-061-1/+5
| | | | | | | | | | | | | | | | | If you are using a repository which contains a .templateconf file that sets TEMPLATECONF to point into a layer it contains, but you aren't using that layer in your bblayers.conf, the eSDK would produce an error during the preparation step of the installation. An example would be using the poky repository but setting DISTRO to your own custom distro and removing meta-poky from your bblayers.conf. The eSDK doesn't support creating new build directories, so we don't care about the templates and can thus force a known good value to prevent this from happening. Fixes [YOCTO #10568]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: explicitly set DL_DIRRoss Burton2016-10-151-0/+2
| | | | | | | | | | | | | | | | | | | | | The eSDK generation assumes that DL_DIR is downloads/ under the build directory, and puts files such as a freshly buily uninative tarball in there expecting bitbake will find it later. Whilst ${TOPDIR}/downloads/ is in fact the default value for DL_DIR in bitbake.conf, and any instances of DL_DIR are removed from the original local.conf, there is still the possibility that other layers could contain a site.conf that assigns DL_DIR. If this happens the errors are quite mysterious as it fails to find the uninative tarball and so the hashes all change, and eSDK building fails. Ensure that this cannot happen by explicitly assigning the DL_DIR that we require, instead of assuming that the default value will be used. [ YOCTO #10439 ] Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: add symlinks and unfsd to support Eclipse pluginPaul Eggleton2016-10-071-2/+12
| | | | | | | | | | | | The Yocto Project Eclipse plugin requires that runqemu and unfsd are accessible within the SDK, and indeed the standard SDK has these. This turns out to be fairly easy to do - we just need to add unfsd and symlink it, runqemu and a few other scripts into the SDK's bin directory. Fixes [YOCTO #10214]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: ensure we clean the right temporary TMPDIR pathPaul Eggleton2016-09-141-3/+4
| | | | | | | | | | | | | | | | | | | After we run the build system within the eSDK internally as part of the sstate filtering that happens during do_populate_sdk_ext, we need to ensure that the TMPDIR created during that process gets deleted. However we were using the TMPDIR path for the build producing the eSDK which may not be the same (since that value would typically be filtered out) thus if the user had set TMPDIR to something other than the default, the temporary TMPDIR would not be deleted which not only led to extraneous junk entering the SDK but also failures during install because the TMPDIR path was different. In order to fix this, force TMPDIR to a known value during the sstate filtering run so we know what to delete afterwards. Fixes [YOCTO #10210]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: exclude image tasks from locked signaturesAmarnath Valluri2016-09-141-1/+1
| | | | | | | | | Tasks for image recipes cannot be locked and should be excluded from eSDK generated locked-sigs.inc. get_sdk_install_targets() was not returning right image targets to be excluded incase of 'minimal' sdk. This change fixes the issue. Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: Put populate_sdk_ext under sstate controlRichard Purdie2016-09-041-1/+10
| | | | | | | | | | Adding populate_sdk task to SSTATE_TASKS should make sstate machinery to generate manifest for deployed ext sdk artifacts and do final deployment to SDK_DEPLOY. This is done in a similar way to do_populate_sdk in a previous patch. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_base: Put populate_sdk under sstate controlEd Bartosh2016-09-041-1/+2
| | | | | | | | | | | | | | | | | | | | | Adding populate_sdk task to SSTATE_TASKS should make sstate machinery to generate manifest for deployed sdk artifacts and do final deployment to SDK_DEPLOY. Set stamp-extra-info flag for do_populate_sdk task. This flag is used in the name of sstate manifest. Setting it to predetermined value for populate_sdk task should help to get correct manifest filenames when processing runQueueTask events. The do_populate_sdk function is also executed by do_populate_sdk_ext so in order to avoid conflicts with the sstate postfuncs, split the main code into a separate function. We also need to set SDKDEPLOYDIR as do_populate_sdk_ext expects it in order not to break ESDK generation. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: add some pre-install checksPaul Eggleton2016-08-171-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check a number of things as early as possible in the eSDK installer script so that the user gets an error up front rather than waiting for the build system to be extracted and then have the error produced: * Check for missing utilities specified in SANITY_REQUIRED_UTILITIES (along with gcc and g++), taking into account that some of these are satisfied by buildtools which ships as part of the SDK. We use the newly added capability to list an SDK's contents to allow us to see exactly which binaries are inside the buildtools installer. * Check that Python is available (since the buildtools installer's relocate script is written in Python). * Check that locale value set by the script is actually available * Check that the install path is not on NFS This does duplicate some of the checks in sanity.bbclass but it's difficult to avoid that given that here they have to be written in shell and there they are written in Python, as well as the fact that we only need to run some of the checks here and not all (i.e. the ones that relate to the host system or install path, and not those that check the configuration or metadata). Given those issues and the fact that the amount of code is fairly small I elected to just re-implement the checks here. Fixes [YOCTO #8657]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: properly determine buildtools filenamePaul Eggleton2016-08-171-6/+11
| | | | | | | | | Determine the name of the current buildtools installer ahead of time, set it in a variable and use that variable rather than the wildcarded version everywhere, since it's much tidier. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: properly handle buildtools install failurePaul Eggleton2016-08-171-2/+4
| | | | | | | | | | | | | If the buildtools installation failed, we were using a subshell instead of a compound command and thus the subshell exited but the script continued on, which is really not what we want to happen. Additionally log the buildtools installer output to a file and cat it if it fails so that you can actually see what went wrong, as well as amending the environment setup script to print a warning as we do when the preparation fails. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: sstate filtering fixesPaul Eggleton2016-08-171-3/+4
| | | | | | | | | | | | | A couple of fixes for the recent sstate filtering implemented in OE-Core revision 4b7b48fcb9b39fccf8222650c2608325df2a4507: * We shouldn't be deleting the downloads directory here, since it contains the uninative tarball that we will need * TMPDIR might not be named "tmp" - in OE-Core the default is tmp-glibc so use the actual name of TMPDIR here instead. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: handle lack of uninative when filtering sstatePaul Eggleton2016-08-171-0/+5
| | | | | | | | | | | | | | If the build in which the eSDK is being built isn't using uninative, this will have an effect on NATIVELSBSTRING, which will mean that the eSDK installer won't be able to find any of the native sstate packages. To keep things simple, under this scenario just disable uninative temporarily while we run the SDK installer to help us check the presence of the sstate artifacts we need. Ideally I'd rather not have things like this that are artificial in this verification step, but on the other hand this was the least ugly way to solve the problem. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: ensure eSDK can build without uninative enabledPaul Eggleton2016-08-171-9/+10
| | | | | | | | | | | | We were relying on uninative being enabled in the build in which the eSDK was being produced, which is not the case for example for OE-Core's default configuration. Move the code that copies the uninative tarball and writes the checksum to copy_buildsystem so that it happens early enough for that part of the configuration to be set up when we do the filtering (which requires running bitbake). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: add gdb to full extensible SDKPaul Eggleton2016-07-251-1/+1
| | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: filter sstate within the extensible SDKPaul Eggleton2016-07-251-6/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: allow including toolchain in eSDK on installPaul Eggleton2016-07-251-1/+18
| | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: set default for SDK_INCLUDE_PKGDATAPaul Eggleton2016-07-251-0/+1
| | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: show progress when preparing build systemPaul Eggleton2016-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: exclude initramfs images from locked signaturesPaul Eggleton2016-07-081-4/+5
| | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: ensure tasks to build the image are includedPaul Eggleton2016-07-081-1/+7
| | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: eliminate double execution on installPaul Eggleton2016-07-071-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/lib: Complete transition to python3Richard Purdie2016-06-021-2/+2
| | | | | | | 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 <richard.purdie@linuxfoundation.org>
* classes/lib: Update to match python3 iter requirementsRichard Purdie2016-06-021-2/+2
| | | | | | | python3 standardises its use of iteration operations. Update the code to match the for python3 requires. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: adjust variable blacklistingPaul Eggleton2016-05-201-0/+4
| | | | | | | | | | | | * Blacklist SSTATE_DIR, DL_DIR and TMPDIR by default to avoid problems such as the one mentioned in [YOCTO #9605]. * Blacklist BB_NUMBER_PARSE_THREADS since we already blacklist BB_NUMBER_THREADS and they may be set separately. Fixes [YOCTO #9605]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: Change lockedsigs task mismatch to a warningRandy Witt2016-05-091-1/+1
| | | | | | | | | | | | | | It has been determined that it is highly likely that users might get signatures that don't match in an extensible sdk. This doesn't necessarily happen with oe-core, so we can set the mismatch to an error during testing if we like. However, for the case where users are creating their own sdks, we don't need an error halting their progress. locked-sigs will still function as it should. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext.bbclass : Show logfile in case the SDK EXT installation failedLeonardo Sandoval2016-05-091-1/+1
| | | | | | | | | | | To avoid lots of output in the SDK EXT installation phase, system redirects it to a logfile ($target_sdk_dir/preparing_build_system.log) but in case of error, the contents should be shown so debugging could be faster. [YOCTO #9576] Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* devtool: Create unlocked-sigs.inc containing items in the workspaceRandy Witt2016-04-081-0/+5
| | | | | | | | | | | | | | | | | | | | When a recipe is added to the workspace, the signatures for the tasks will change. This means that bitbake must be told to allow the signatures to be different if they are in locked-sigs.inc. This is done by creating an unlocked-sigs.inc file which contains all the recipes in the workspace each time devtool reads the workspace. So not only will necessary things get added, previously added items will be removed by virtue of them no longer being in the workspace. This also makes sure that the extensible sdk picks up unlocked-sigs.inc as part of the configuration. [YOCTO #9195] Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext.bbclass: Enable locked sigs errorsRandy Witt2016-04-081-2/+9
| | | | | | | | | | | With the extensible sdk we want there to be an error if a task tries to run without signatures that match locked-sigs.inc. This patch enables that error. [YOCTO #9195] Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Exclude BBTASKDEPDATA from task signatureRichard Purdie2016-04-031-0/+2
| | | | | | | | Otherwise the task hash changes between server and worker context leading to changing task checksums. The dependency data here is tracked by other pieces of the signature. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oe-publish-sdk: exclude sstate-cache if publishing minimal SDKPaul Eggleton2016-03-311-0/+6
| | | | | | | | | | | | | | | | | | | | | If SDK_EXT_TYPE is set to "minimal" then the SDK won't contain many sstate artifacts, and you're required to set up an sstate mirror in this case anyway so there's no point publishing the "stub" sstate-cache directory from within the SDK since it won't be useful for update purposes and may be confused with the real sstate-cache. There is however a possibility that people might publish the real sstate-cache directory under the same output directory provided to oe-publish-sdk, thus deleting it after extracting (as we were doing with other files we wanted to clean up at the end) would be problematic, besides which extracting it and then deleting it is wasteful. Thus, introduce a "-p" command line option to the SDK installer that we can use to tell tar not to extract the items we don't want when publishing. This has the added benefit of mostly keeping references to these in the place they belong i.e. in populate_sdk_ext.bbclass. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: support setting vars from environment at build timePaul Eggleton2016-03-311-0/+20
| | | | | | | | | | | | | | | | | | | | When running bitbake you may pass in values of variables from the external environment (making use of BB_ENV_EXTRAWHITE), and you may choose to do this when building the extensible SDK, for example: MACHINE=qemuarm bitbake -c populate_sdk_ext core-image-minimal You would naturally expect those settings to be reflected in the extensible SDK itself; however they were not, since we were only considering local.conf and auto.conf. Check the variables mentioned in BB_ENV_EXTRAWHITE to see if any are different than the values set in local.conf/auto.conf and add lines setting them in the SDK's local.conf if so. Fixes [YOCTO #9339]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uninative: Switch md5sum -> sha256Richard Purdie2016-03-301-1/+1
| | | | | | There are various concerns about md5 so use sha256 instead. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: parse metadata on minimal SDK installPaul Eggleton2016-03-231-1/+1
| | | | | | | | | | 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. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Correct commit 8b81bb56c69aabdea984352f8e267a9783c0bdbcRichard Purdie2016-03-091-1/+0
| | | | | | | | | | | | Commit 8b81bb56c69aabdea984352f8e267a9783c0bdbc was accidentally merged. The DL_DIR piece was simply incorrect and should be removed. The patch commit message should have mentioned that the changes were to update populate_sdk_ext after the changes to uninative now the download is placed into a specific directory in DL_DIR. We also need to specify the uninative tarball checksum. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Make populate_sdk_ext nostampRandy Witt2016-03-091-3/+4
| | | | | | | | | | | | | | | Since the metadata for multiple layers will be put into the sdk, anytime those layers change the sdk needs to be rebuilt. Ideally, this would use checksums to only rebuild when necessary. However, since this feature needs to be in the release, opt for a less intrusive change by setting the task to nostamp. Unnecessary rebuilds may occur, but it's better than a user wondering why their changes didn't get added. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Update after uninative changesRichard Purdie2016-03-091-4/+8
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add build-sdk subcommandPaul Eggleton2016-03-041-59/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a build-sdk command which is only available within the extensible SDK that builds a derivative extensible SDK. The idea is recipes in the workspace become a part of the new SDK - for example, this allows taking a vendor provided SDK, adding a few libs and then producing a new SDK with those included. When normally building the extensible SDK, the workspace is excluded; here we need to copy into the new SDK (renaming it in the process); the recipes' task signatures become locked and thus the sources are no longer needed, so they are removed along with the workspace bbappends which would interfere with the locked signatures. Additionally we need to just copy the configuration files (i.e. local.conf and auto.conf) rather than filtering and appending to them since that work has already been done when constructing the original SDK. The extra sstate artifacts from workspace recipes are also determined and copied into the new SDK in minimal mode (on the assumption that you won't set up a new sstate mirror). This reuses some code from build-image, so that needed to be generalised to allow that. Implements [YOCTO #8892]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Only write LCONF_VERSION to bblayers if it is setRandy Witt2016-03-021-1/+6
| | | | | | | | | | It is possible that LCONF_VERSION won't be set, such as if meta-poky is used. Without this change, bblayers.conf would have LCONF_VERSION = "None" if LCONF_VERSION wasn't set, which would cause a sanity check failure. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Delete the buildtools tar file after installationRandy Witt2016-03-021-0/+3
| | | | | | | | | | | When installing the ext sdk, buildtools is extracted and installed as well. The tar file containing buildtools isn't used after installation so was wasted space and clutter. [YOCTO #9172] Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: prepend to PATH rather than appendingPaul Eggleton2016-03-021-1/+1
| | | | | | | | | | | | | | The rest of the environment setup script prepends to PATH, so when we add the path to run devtool we should be prepending as well. This also ensures that when you run the environment setup script from extensible SDK installation A and then in the same shell session run the environment setup script from installation B, and then run devtool, that you're running B's devtool and not A's. Fixes [YOCTO #9046]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: Add images to SDK_INSTALL_TARGETSRandy Witt2016-02-281-1/+9
| | | | | | | | | | | | | When running ext-sdk-prepare.py during sdk installation a check is done to make sure no tasks would run that aren't provided by the "leaf" recipes specified in SDK_INSTALL_TARGETS. However sometimes an image recipe can cause other images to be created such as an initramfs. So make sure those additional images are recognized by ext-sdk-prepare.py and don't flag an error. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* classes/populate_sdk_ext: add a better config extension mechanismPaul Eggleton2016-02-211-0/+8
| | | | | | | | | | | | The sdk_extraconf() method of setting the configuration was awkward since you needed to set it in a class and then inherit that class since function definitions aren't allowed in conf files. It seemed to me the a neater way to do this was to read the extra lines from an additional conf file sdk-extra.conf (which can be located in a conf/ directory anywhere along BBPATH as with other configuration files). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext.bbclass: Add SDK_RECRDEP_TASKS variableRandy Witt2016-02-211-1/+3
| | | | | | | | | | | | | | | | Currently there isn't a way for the extensible sdk to know all the tasks that will need sstate for an image. This is because a layer can add it's on custom tasks that are required for an image to be generated. The extensible sdk solved this for poky by using recrdeptask and specifying the tasks known to be required for the image as well as for building new recipes. So the SDK_RECRDEP_TASKS variable allows a user to specify additional tasks that need to be pulled in. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Don't ignore SDK_TARGETS valueRandy Witt2016-02-211-1/+12
| | | | | | | | | This fixes a problem where SDK_INSTALL_TARGETS wouldn't pick up the value in SDK_TARGETS. It also removes the inline python to make the code more readable. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: Add SDK_EXT_TARGET_MANIFEST and SDK_EXT_HOST_MANIFESTAníbal Limón2016-02-101-0/+3
| | | | | | | | | | Extensible SDK needs to point to the correct manifest so add SDK_EXT_TARGET_MANIFEST and SDK_EXT_HOST_MANIFEST variables. oeqa/oetest.py: Fix SDKExtTestContext for load the correct manifests. Signed-off-by: Aníbal Limón <limon.anibal@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: Set TOOLCHAINEXT_OUTPUTNAME.Aníbal Limón2016-02-101-1/+2
| | | | | | | | This variable is needed by testextsdk to known the name of extensible sdk file generated. Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* populate_sdk_ext: Make populate_sdk_ext depend on sdk_extra_confRandy Witt2016-02-061-2/+3
| | | | | | | | If a user changes sdk_extra_conf, it should cause populate_sdk_ext to run. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>