summaryrefslogtreecommitdiffstats
path: root/meta/classes/populate_sdk_ext.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* populate_sdk_ext: Change lockedsigs task mismatch to a warningRandy Witt2016-05-111-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. (From OE-Core rev: 6ba86d847275126bf435f144e7d029d10e7ab17d) 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.bbclass : Show logfile in case the SDK EXT installation failedLeonardo Sandoval2016-05-111-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] (From OE-Core rev: 227d2cbf9e0b8c35fa6644e3d72e0699db9607fa) Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Create unlocked-sigs.inc containing items in the workspaceRandy Witt2016-04-091-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] (From OE-Core rev: 6b2b5ffdcb8bf885a1c756ea132e9d2c55e13dcd) 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-091-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] (From OE-Core rev: fad9bbba1154d68b5dc808d2976aa6484cd49c91) 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. (From OE-Core rev: 1962571a7358fb9c9af2d6cfd1a01673b0d18193) 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. (From OE-Core rev: 774b85d42db1d81936d4e4af4f6fb2c57cb51d2c) 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]. (From OE-Core rev: 2bfed75c48a6f6596ded9cb64cb96f00510f914e) 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-311-1/+1
| | | | | | | | There are various concerns about md5 so use sha256 instead. (From OE-Core rev: a88603cb2ffd4f995e16349a389902eb884252e5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: parse metadata on minimal SDK installPaul Eggleton2016-03-251-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. (From OE-Core rev: 6b38a991a3475fb82889428b94563968c7570473) 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. (From OE-Core rev: be177739b46d3296c0c0c01310b499ffc6782d43) 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. (From OE-Core rev: d801547f6fe4315da6476ed9fc4ccca2a6983421) 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
| | | | | | (From OE-Core rev: 8b81bb56c69aabdea984352f8e267a9783c0bdbc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add build-sdk subcommandPaul Eggleton2016-03-071-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]. (From OE-Core rev: 59e207ff6dd4b50a8905e14bc9292cf2794f4e7a) 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. (From OE-Core rev: 914b0a99997d8c69eafcb34dd982f46540eed882) 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] (From OE-Core rev: 0dc7d3179a605c10987ee836dd179ffeb14d0ba5) 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>
* 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]. (From OE-Core rev: b7ac987274f7aeaeacc217488cf4fe639de81b76) 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>
* 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. (From OE-Core rev: 6eb75df1000ce1905e83840204adb614659d25cf) 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>
* 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). (From OE-Core rev: b53edb86c65ad375df153017f245244ef97f3932) 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. (From OE-Core rev: 4236b9653f6dfbddc937108bbbd9a9445eb81382) 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. (From OE-Core rev: 5b7bc7ab44c2cc5d5f217d9ad81a210ea053dc85) 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. (From OE-Core rev: 2310d5ad03531b7e1f9572c12c83c2fedc0291c9) Signed-off-by: Aníbal Limón <limon.anibal@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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. (From OE-Core rev: e4cf46f240dda6263ba3ba14cd63087cce166f1c) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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. (From OE-Core rev: 5de9b123f35a62a0a81f434a10492cdd92668ef0) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Add support for a "minimal" typeRandy Witt2016-02-061-7/+8
| | | | | | | | | | | If the user sets the SDK_EXT_TYPE variable to "minimal" then the sdk won't contain any sstate. The sstate can come from an sstate mirror and be installed on demand as usual. (From OE-Core rev: 35f79652ab5f1ca754fb726a9bc88d0add0114c8) 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 set sdk_update_targets in the configRandy Witt2016-02-061-1/+0
| | | | | | | | | | sdk_update_targets isn't used by any code, so there is no reason to set it. (From OE-Core rev: e9349939e22ca9cf0efe0795291c01fbdeb96a8c) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Add SSTATE_MIRRORS to config blacklistRandy Witt2016-02-021-1/+6
| | | | | | | | | | | | | SSTATE_MIRRORS used by the builder may not be the same as what the installer of the sdk will use. Therefore blacklist SSTATE_MIRRORS from the builder configuration. Note: the actual SSTATE_MIRRORS for the sdk can be added using sdk_extra_conf. (From OE-Core rev: 3ddd6c8409b0365aa58b7dd0b2218a1f7ef05a4c) 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>
* classes/populate_sdk*: add dependencies on script filesPaul Eggleton2016-01-241-0/+5
| | | | | | | | | | | If the script files we use to construct the SDK installer change then that really ought to trigger re-execution of the do_populate_sdk(_ext) task, so add file-checksums varflags to ensure that happens. (From OE-Core rev: 59fc4bdefb3853d6893b9e3792018d54bb6bf99f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: drop ext-sdk-prepare.py when installingPaul Eggleton2016-01-241-0/+1
| | | | | | | | | | | | At the end of the extensible SDK installation, if we've successfully prepared the build system then we don't need ext-sdk-prepare.py. I had thought earlier that this would be used when updating, but a different mechanism was needed there so this script isn't used for that. (From OE-Core rev: 037ea78b0c3de01f87bbe06a1b88a162b2b40496) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sdk-update: improve SDK update process robustnessPaul Eggleton2016-01-241-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the following improvements to the SDK update process: * Use a manifest file with sha256sums to track files other than sstate and metadata that we need to update - e.g. conf files. This allows us to handle where files such as auto.conf may or may not be present, as well as the configuration changing without affecting task signatures - we still want the config files copied in that case rather than it saying nothing needs to be done. * Write the SSTATE_MIRRORS_append to site.conf rather than local.conf so that local.conf remains static (since we don't want to trigger an update every time). Also, If there is an SSTATE_MIRRORS value already set in the configuration we can skip this and assume it contains the needed packages. * Allow the update process to be run in any directory, don't assume we're already at the base of the SDK * Where practical, fetch remote files into a temporary location and then move them to the desired location at the end, to avoid a failed update leaving the SDK in a broken state. * Update all installed do_populate_sysroot / do_packagedata tasks instead of using the SDK targets. This ensures any item installed through dependencies after installation (e.g. when running "devtool build") won't go stale. (From OE-Core rev: 3d35631121f0e030bc8151f5c23d84008d06f44b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: add option to bring in pkgdata for worldPaul Eggleton2016-01-241-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a variable SDK_INCLUDE_PKGDATA which you can set to "1" to include pkgdata for all recipes in the world target. There are a couple of uses for this: 1) If you use "devtool add" to add a recipe that builds something which depends on anything in world, the dependency can then be correctly mapped to the recipe providing it and that recipe can be added to DEPENDS, since we have the pkg-config and shared library dependency data within pkgdata. 2) You'll be able to search for these recipes and any files they package for the target with "devtool search" since that also uses pkgdata This of course assumes you've tailored world through EXCLUDE_FROM_WORLD to only include recipes you'd want built in your distro, but I think that's a reasonable assumption; failing that there is a WORLD_PKGDATA_EXCLUDE variable that you can set to exclude any recipes you don't want. Note that this patch relies on functionality implemented in a recent BitBake patch and will not work without it. Implements [YOCTO #8600]. (From OE-Core rev: 67149ea097d6fab7496b43e85a40853f40bd527e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: fix task dependency regressionPaul Eggleton2016-01-191-3/+3
| | | | | | | | | | | | | | | | | Fix a regression caused by OE-Core revision eabeb26335b1a4eb1e68218160dbdbe8fdf36272 where we lost the task dependency on packages in TOOLCHAIN_HOST_TASK (such as meta-environment-extsdk-${MACHINE}) which led to errors about missing packages when building the extensible SDK. This happened because I only moved half of the dependencies coming from the standard SDK task to do_sdk_depends. While I'm at it, tidy up the do_populate_sdk_ext[depends] line. (From OE-Core rev: 80309a2ba25de219b5339f1af6d5052d6229b676) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: avoid unnecessary sstate being brought inPaul Eggleton2016-01-151-7/+20
| | | | | | | | | | | | | | | | Create a separate task where we can just have the recursive dependencies for the tasks corresponding to constructing the SDK content (i.e. from the image contents). This avoids us recursing into dependencies from buildtools and getting a bunch of nativesdk stuff, for example. (This isn't an ideal way to have to implement it, but without overcomplicating things on the BitBake side just for this use-case I can't see a better way.) (From OE-Core rev: eabeb26335b1a4eb1e68218160dbdbe8fdf36272) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: check that extensible SDK prepared correctlyPaul Eggleton2016-01-151-3/+2
| | | | | | | | | | | | | 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>
* classes/populate_sdk_ext: support auto.confPaul Eggleton2016-01-151-0/+13
| | | | | | | | | | | | | If auto.conf exists in the user's configuration we need to also run it through the same filter and write the result into the ext SDK, or we risk missing configuration applied on an autobuilder. Fixes [YOCTO #8904]. (From OE-Core rev: fb0a34a00f3eb10935a3fca4d0af74ae4de4f9a5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext.bbclass: handle if local.conf doesn't end with a ↵Paul Eggleton2016-01-151-0/+2
| | | | | | | | | | | | | | | | newline If there is no newline at the end of local.conf, appending INHERIT = "uninative" won't work, it will corrupt the line and the installed eSDK will build things, making the "Preparing build system..." step take an age. Fixes [YOCTO #8897]. (From OE-Core rev: 1e641f09e8cf0ba716c3d2aade0845abecc27827) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Pass excluded_targets as a list to prune_lockedsigsRandy Witt2016-01-111-1/+1
| | | | | | | | | | prune_lockedsigs expects excluded_targets to be a list, whereas previously it was passed in as a string. (From OE-Core rev: db3cd1e08b08b99342d269882f31ec7e1daba2c6) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Change to include siginfo and non sstate task sigsRichard Purdie2016-01-111-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Right now, the locked task hashes list for the extensible SDK locks down only the sstate tasks. Whilst asthetically pleasing, this gives two problems: * Half the task are left floating meaning checksum mismatches are a pain to debug * The later code which copies relavent data files out the sstate cache can't use any of this data. This patch modifies things so all the checksums are listed in the locked file. An exclusion of tasks probably makes more sense for the library function rather than an allowed list. The only sstate task being deliberaly excluded here was do_package so add in a function to explictly exclude those sstate object files. The net result of this that siginfo files for all tasks are included in the SDK, which means commands like "bitbake -S printdiff" now function. (From OE-Core rev: 6b70479e47b8a8743d8b410d6bc08da1607a318e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: disable signature warningsPaul Eggleton2016-01-111-1/+1
| | | | | | | | | The user of the extensible SDK doesn't need to see these. (From OE-Core rev: 7045fabf73d4eef9c023edb9e0a8b8d1d3f04680) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: fix cascading from preparation failurePaul Eggleton2016-01-111-1/+1
| | | | | | | | | | | | | | During extensible SDK installtion, if the build system preparation step fails we try to put something at the end of the environment setup script to show an error when it is sourced, in case the user doesn't realise that the partially-installed SDK is broken. However, an apostrophe in the message (actually a single quote) appears to terminate the string and therefore breaks the command. Drop it to avoid that. (From OE-Core rev: 21e591d182e24c399ae010a8eff9b89947061a46) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* buildhistory: improve support for extensible SDKPaul Eggleton2015-12-281-0/+3
| | | | | | | | | | | | | | | * Ensure extensible SDK and standard SDK go into their own directories * Record extra extensible SDK variables * Write sstate-package-sizes.txt and sstate-task-sizes.txt files so you can analyse the size of the contents * Add BUILDHISTORY_SDK_FILES (similar to BUILDHISTORY_IMAGE_FILES) and default it to pick up config files installed in the extensible SDK (From OE-Core rev: 5f87ff116d9ccd5e95e638dfa84583169a3f99f3) 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: error out of install if buildtools install failsPaul Eggleton2015-12-281-1/+1
| | | | | | | | | | If the installation of buildtools fails then we should fail the entire installation instead of blindly continuing on. (From OE-Core rev: 34bb63e6c72fb862e0ef0d2b26e1bfddaf7ddb99) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: hide build configuration in devtool build* outputPaul Eggleton2015-12-281-0/+3
| | | | | | | | | | | | The configuration of the build system within the extensible SDK is fixed, so there's not a lot of point in showing it; plus it just gets in the way of the output that's interesting to the user in this context. So let's hide it within the extensible SDK. (From OE-Core rev: 6223b73c2dfc326382dbd3c0ae2d7a0cf2cc3b48) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: use uninative to set NATIVELSBSTRINGPaul Eggleton2015-12-281-5/+2
| | | | | | | | | | | | | We inherit uninative in the extensible SDK configuration, and uninative sets NATIVELSBSTRING to a fixed value, so we don't need to force the value ourselves. Fixes [YOCTO #8662]. (From OE-Core rev: 918814c05d670bccb05d61fa848fd0d93da3a7b0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext/sign_rpm/sign_package_feed: Add missing getVar parameterRichard Purdie2015-12-141-1/+1
| | | | | | | | We should always pass a parameter to getVar, add missing default value. (From OE-Core rev: 31bc0a46a97d7dc98568a218c077c31d8b11dbd9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext.bbclass: Be more permissive on the name of the buildtoolsMark Hatle2015-12-011-4/+1
| | | | | | | | | | | | | | | | | | We want to support different names for the buildtools tarball. The name may not always be of the default oe-core format. For instance, at Wind River we define the built-tools name to be: ${SDK_ARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION} because thes standard SDK_NAME has additional information that is not relevant to the builtools tarball. (From OE-Core rev: b49c6f179b06a8b97106aa4c95f2cdb3c4dc0920) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: fail if SDK_ARCH != BUILD_ARCHPaul Eggleton2015-12-011-0/+5
| | | | | | | | | | | | | | | The extensible SDK relies upon uninative, and with the way that uninative works, the build system architecture must be the same as the SDK architecture or the extensible SDK won't be usable. At some point in future hopefully we can remove this limitation, but until then it's disingenuous to allow this to build, so add a check to ensure SDK_ARCH == BUILD_ARCH and fail if it isn't. (From OE-Core rev: 9e30e849eda3b0a0c54d3f7ed0102760fdaef06c) 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: tweak reporting of workspace exclusionPaul Eggleton2015-12-011-1/+1
| | | | | | | | | | | | | | | If you have a local workspace layer enabled when building the extensible SDK, we explicitly exclude that from the SDK (mostly because the SDK has its own for the user to use). Adjust the message we print notifying the user of this so it's clear that we're excluding it from the SDK, and scale it back from a warning to a note printed with bb.plain(). (From OE-Core rev: 90f46f74a088a7b965d2205eceb9eff6f276dd38) 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: make it clear when SDK installation has failedPaul Eggleton2015-12-011-1/+1
| | | | | | | | | | | | | | | | | When SDK preparation fails: * Insert an ERROR: in front of the error message * Add an error message to the environment setup script Hopefully this should make it more obvious when this happens. Fixes [YOCTO #8658]. (From OE-Core rev: 105df569b3b1982005c2edb37f4690f9ba6bde35) 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: tidy up preparation log file writingPaul Eggleton2015-12-011-1/+2
| | | | | | | | | | | | | Use a variable for the log file which includes the full path; this is not only neater but avoids us writing the first part (the output of oe-init-build-env) to a file in another directory since we are changing directory as part of this subshell. (From OE-Core rev: 001af71752a9e9aab460cbd49ed049e1eb726295) 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: detect and warn if running in OE environmentPaul Eggleton2015-10-201-0/+3
| | | | | | | | | | | | | | If you run the extensible SDK environment setup script in a shell session where oe-init-build-env has been run already, and attempt to use the two together, strange things happen - you may not even be running devtool from the extensible SDK, but the OE tree. This isn't a supported use case anyway, so show a warning recommending starting a new shell session. (From OE-Core rev: 41afc48ab979dff6ebb3ea4003dd6baefff7f644) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-09 02:02:20 +0000