summaryrefslogtreecommitdiffstats
path: root/meta/classes/populate_sdk_ext.bbclass
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* classes/populate_sdk_ext: add warning against editing configurationPaul Eggleton2015-04-241-0/+10
| | | | | | | | | | | It may be tempting to edit the configuration of the encapsulated version of the build system, however that is not the way it is intended to be used, so add a warning against doing this. (From OE-Core rev: 80bbd763448fa061e3dbc3ace8d6bc9f65e4bfaf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: disable network connectivity checkPaul Eggleton2015-04-241-0/+3
| | | | | | | | | | | | Most of the time we shouldn't be downloading anything within the extensible SDK (since it's all pre-built and we have the sstate artifacts) therefore there's really no need for a connectivity check, in fact it may just get in the way. (From OE-Core rev: beaf851ae8aadb5b9e3c0b9840479efcbb05be23) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Log the "Preparing build system" stepRandy Witt2015-03-311-1/+1
| | | | | | | | | | | | | When using bitbake to do the setscene as part of sdk setup, it would be useful to have a log in the case where it fails. The log is called preparing_build_system.log and is in the top level directory of the extracted sdk. (From OE-Core rev: 698019f6bb1f72f079cc2cb051e665620bf551a3) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: add extensible SDKRandy Witt2015-02-241-0/+217
This bbclass will create an SDK with a copy of bitbake and the metadata and sstate for the target specified for the task. The idea is to let "system" developers both work on applications and then test adding them to an image without having to switch between workspaces or having to download separate items. Rather than running bitbake directly however, the primary way of running builds within the extensible SDK is to use the "devtool" command. The rest of the build system is fixed via locked shared state signatures, and thus only the recipes you have added get built. (From OE-Core rev: bf81d6bb7f6df5405b8f2148e2a22e0030c12757) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-28 02:45:41 +0000