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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Richard Purdie
Randy Witt
Paul Eggleton
Aníbal Limón
Aníbal Limón
Mark Hatle
Qi.Chen@windriver.com