summaryrefslogtreecommitdiffstats
path: root/meta/classes/populate_sdk_ext.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* classes/populate_sdk_ext: add note to env setup scriptPaul Eggleton2015-10-201-0/+2
| | | | | | | | | | Print a note at the end of the environment setup script pointing to devtool. (From OE-Core rev: ea1d566bc2ff61f2e086effb9ca6551b263eacbe) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: prevent image construction from executing on installPaul Eggleton2015-10-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | | In order to prepare the build system within the extensible SDK, we actually go ahead and build the targets specified by SDK_TARGETS (by default the image the SDK was built for). Assuming that's an image, we don't actually need to build the image itself - we just need to have everything done up to the point before building the image, so that we have everything needed in the sysroot. In order to do this, create temporary bbappends for each of the targets in the workspace layer that stub out do_rootfs and related tasks if they exist. This is a little bit of a hack but is the least intrusive fix at this point. To make things a bit tidier, I have split out the preparation commands into a separate script so we can run that in the appropriate environment rather than all the commands separately. Fixes [YOCTO #7590]. (From OE-Core rev: d2a2962897b89731a5705b0cbc7c6f36aa53dcc8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: consistent indentationPaul Eggleton2015-10-201-5/+5
| | | | | | | | | | Make indentation consistent here in preparation for the changes that follow. (From OE-Core rev: 59a3789c678bf58c0a04b8def416246654680841) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: drop work-config.incPaul Eggleton2015-09-231-5/+0
| | | | | | | | | | | | | This is not actually used for anything - I thought that we would need to use it within devtool to set global configuration, but we're able to do everything we need within the bbappends it creates, which also saves on parse time. If we're not going to use work-config.inc let's just drop it completely. (From OE-Core rev: 84a1f82acd3b6ebb3c073aae6b996d2203dad2ce) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: allow custom configuration for extensible SDKPaul Eggleton2015-09-231-0/+7
| | | | | | | | | | | Provide the ability to define a function containing extra configuration values to be added to the local.conf file that goes into the SDK. For example, this could be used to set up SSTATE_MIRRORS within the SDK. (From OE-Core rev: ef7001232ac2da8ee63ec568d1abba13e4fd4382) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: fix missing environment settings if running ↵Paul Eggleton2015-09-231-3/+4
| | | | | | | | | | | | | | | | | | | | installer with sh If you ran the extensible SDK installer file with sh (instead of bash), then the additional call to buildtools environment setup, extension of PATH to support running devtool, and setting of OE_SKIP_SDK_CHECK weren't being added to the end of the script. This is because apparently bash is happy to expand wildcards in the target of a redirection, but bash running in POSIX sh mode won't (although it apparently does work on the sh command line rather than within a script run as an argument to sh). In any case using a wildcard here is a bit of a crutch which we don't need, so replace it with the proper path to the environment setup script. (From OE-Core rev: ba0f6b6ec32275329ebbb7c27f661c027b7a921d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add mechanism for updating extensible SDKQi.Chen@windriver.com2015-09-091-0/+6
| | | | | | | | | | | | | | | | | | | | | Enable updating the installed extensible SDK from a local or remote server, avoiding the need to install it again from scratch when updating. (This assumes that the updated SDK has been built and then published somewhere using the oe-publish-sdk script beforehand.) This plugin is only enabled when devtool is used within the extensible SDK since it doesn't make sense to use it next to a normal install of the build system. E.g. devtool sdk-update /mnt/sdk-repo/ devtool sdk-update http://mysdkhost/sdk (From OE-Core rev: 32cbd4c57fc8ca097a18929fc404c07322ef36dd) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Extensible SDK: allow for installation without preparing build systemQi.Chen@windriver.com2015-09-091-5/+7
| | | | | | | | | | | | | | When publishing SDK, what we want is basically its metadata and sstate cache objects. We don't want the SDK to be prepared with running bitbake as it takes time which reproduces meaningless output for the published SDK. So this patch adds an option to allow for SDK to be extracted without preparing the build system. (From OE-Core rev: 7511862faad1c28804e2410ff42747c8706c5207) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: don't remove the native qemu dependenciesQi.Chen@windriver.com2015-09-091-5/+0
| | | | | | | | | | | | | | | These dependencies were deliberately removed because it was assumed that they were provided by nativesdk packages. On the one hand, nativesdk packages in extensible SDK don't have these packages; on the other hand, even if we add these nativesdk packages, they are still not useful because we we need runqemu to run correctly. So we don't remove these native qemu dependencies. (From OE-Core rev: 526537404d5a07189d4c6859f4a572d2107dbfd8) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: consider custom configuration in local.confQi.Chen@windriver.com2015-09-091-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Copy the contents of local.conf under TOPDIR into the final generated local.conf. In this way, custom settings are also made into the final local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx, etc. Comments and blank lines are filtered out. Before this change, installing extensible SDK would usually report failure when preparing the build system if the user has custom configuration for DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in local.conf also don't get built correctly. This patch solves the above problem by making use of bb.utils.edit_metadata. In addition, we check to avoid any setting that might lead to host paths bleeding into the SDK's configuration. Basically, variables with values starting with '/' are removed. A whitelist mechanism is introduced so that users could specify variables that should not be ignored. The name of the whitelist is SDK_LOCAL_CONF_WHITELIST. The SDK_META_CONF_WHITELIST is removed as it's of no use after this change. SDK_LOCAL_CONF_BLACKLIST can be used to prevent copying specific variable settings to the extensible SDK's local.conf; the default is to exclude PRSERV_HOST (since this is likely to be internal). Similarly, SDK_INHERIT_BLACKLIST to forbit local.conf in SDK to inherit certain classes such as 'buildhistory' or 'icecc' that would not normally make sense in an SDK environment. [YOCTO #7616] (From OE-Core rev: 0dda443bfa5c42f327d8d0ed7b23af11c156a60e) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: install the latest buildtools-tarballQi.Chen@windriver.com2015-09-091-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | If we do `bitbake buildtools-tarball' and then after one day do `bitbake core-image-minimal -c populate_sdk_ext', we would meet errors like below. | install: cannot stat '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/ poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standalone -1.8+snapshot-20150429.sh': No such file or directory The problem is that the output name for buildtools-tarball has ${DATE} in it. So if populate_sdk_ext task is executed but buildtools-tarball is not rebuilt, the above error appears. Instead of hardcoding ${DISTRO_VERSION} which consists of ${DATE} in the install_tools() function, we should find the latest buildtools-tarball based on the modification time and install it. [YOCTO #7674] (From OE-Core rev: fa708504d71e0b01ee97a172ac17ad16a9e3b897) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: avoid poky-specific buildtools namingPaul Eggleton2015-09-091-1/+1
| | | | | | | | | | | | | Only poky sets SDK_NAME to include ${IMAGE_BASENAME} (i.e. ${PN}), so we can't assume the buildtools filename will include it here. Change it to look for a file with "buildtools-nativesdk-standalone" in the name (the buildtools-tarball recipe itself sets TOOLCHAIN_OUTPUTNAME to include this.) (From OE-Core rev: 78ea4fcdea468888c0faef22a95dea7015a91df2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: pass BBPATH to devtool --bbpathChristopher Larson2015-08-011-1/+2
| | | | | | | (From OE-Core rev: 6ffb07715a289e2d3f57f4262beb92acb7280ea0) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: use lnr, not ln -sr, for portabilityChristopher Larson2015-08-011-2/+2
| | | | | | | | | Not all hosts are running sufficiently new coreutils. (From OE-Core rev: 3a813f277f8daa7686e26edc87f6a88724adde4e) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* extensible sdk: Error when trying to install as root.Randy Witt2015-07-201-0/+11
| | | | | | | | | | | | | | | | | | | Since the extensible sdk uses bitbake, which can't run as root, the sdk shouldn't be installed as root. Previously it would error out late into setup when bitbake errored saying not to run bitbake as root. Now the script errors with a message saying the extensible sdk can't be installed as root. [Yocto #7545] (From OE-Core rev: 309e8f4e536148056223f50637ed291c48d148ca) 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>
* meta: Add explict getVar param for (non) expansionRichard Purdie2015-06-231-2/+2
| | | | | | | | | | | | | | Rather than just use d.getVar(X), use the more explict d.getVar(X, False) since at some point in the future, having the default of expansion would be nice. This is the first step towards that. This patch was mostly made using the command: sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *` (From OE-Core rev: ab7c1d239b122c8e549e8112c88fd46c9e2b061b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_base: Show title in SDK installerPaul Eggleton2015-04-241-0/+2
| | | | | | | | | | | | Show a friendly title when running the SDK installer, so the user knows what SDK they are installing. The title is controlled by the SDK_INSTALLER_TITLE variable and includes the distro name and SDK version by default. (From OE-Core rev: 0af913887f4c0a79c6b950bd5d57c06333520a14) 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 2025-01-17 06:07:42 +0000