xz gives *much* faster decompression times for the SDK which in itself
is a good reason to use it. It also gives better compression.
One downside is its slower but we care about the end user case
first, build performance secondary.
It also assumes the SDK user has a tar capable of understanding a xz
compressed file but that should be common enough now.
(From OE-Core rev: 193086137b899a0a4e774ffc337ed0da9947fd4f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a second regression in the extensible SDK installation caused by
OE-Core revision 6d2074d477596971dc52027dd87b02af7f39138d - the HOME
environment variable was being cleared, thus using ~/ in the install
path (which is in the default path for the extensible SDK) resulted in a
directory named '~' being created in the current directory.
(From OE-Core rev: 18dcf8acc9a918d00c3525e9af5f64d237f74bdb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE-Core revision 6d2074d477596971dc52027dd87b02af7f39138d we added a
line which re-executes the script with a cleaned environment using
env -i; unfortunately that caused a regression in the extensible SDK on
Ubuntu 14.04 - strangely, there it seems that the value you get for PATH
under env -i contains '.' which triggers a sanity check failure when
preparing the build system. Do a belt-and-braces fix - source
/etc/environment if it exists (so you get a more complete PATH value)
and then filter any nastiness out of PATH for good measure. (Ubuntu
15.04 doesn't seem to suffer from the same problem.)
(From OE-Core rev: 5175d9a6955c1783fc35ab6832b6be4cbb9fc01b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildtools-tarball uses a custom env setup script, which isn't named the
same as the default; thus unfortunately OE-Core revision
a36469c97c9cb335de1e95dea5141038f337df95 broke installation of
buildtools-tarball. Revert that and implement a more robust mechanism.
(From OE-Core rev: 00e081b81ba8118959b724269ba9d18d42aba8a4)
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>
Fixes [YOCTO #8698] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=8698
If prior to running the toolchain installation script a toolchain
environment script is sourced then the toolchain installation will
fail. This because the environment is now set for the sourced toolchain
and doesn't suit the installation. In particular PATH points to the
toolchain executables.
The fix makes the script recursively call itself a second time with a
clean environment.
Tested by sourcing a previous successfully installed environment, erasing the
previous installation directory and then reinstalling in the same directory.
(From OE-Core rev: 6d2074d477596971dc52027dd87b02af7f39138d)
Signed-off-by: George Nita <george.nita@enea.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you put an $ character in the path, SDK installation fails during the
preparation stage, so add this to the disallowed characters.
Fixes [YOCTO #8625].
(From OE-Core rev: 654f4785f719552f4e78e14a5a901c07d00ce68d)
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>
Print a line that's the full length of the title that it's underneath.
(From OE-Core rev: 83729437c584fc74577a2b15dbb2ae094788339d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The toolchain install script suggest the user to source env_setup_script
from wrong path now. eg:
" Each time you wish to use the SDK in a new shell session, you need to
source the environment setup script e.g.
$ . /opt/poky/2.0//opt/poky/2.0/environment-setup-armv5e-poky-linux-gnueabi
"
fix it.
(From OE-Core rev: b388468deda8d81df80d1509226196a5390183a8)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently a lib32-core-image-* SDK prints an incorrect environment-setup-*
file name when installing the SDK. Instead of printing the wrong thing, list
the environment setup files present in the SDK.
As it happens this fixes the message printed with buildtools-tarball too
which someone reported to me about the same time as I finished this patch!
(From OE-Core rev: c2fa59f46bbc86985e6c8e4d5d514a07a9ade884)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed when sh is bash:
$ sh ./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-1.8+snapshot.sh
Poky (Yocto Project Reference Distro) SDK installer version 1.8+snapshot
===========================================================
./tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-1.8+snapshot.sh: 77: read: Illegal option -e
You are about to install the SDK to "/opt/poky/1.8+snapshot". Proceed[Y/n]? ../SDK2
Installation aborted!
There is ony one bashism "read -e" in toolchain-shar-extract.sh, but
'-e' is useless here, so remove it and use /bin/sh.
(From OE-Core rev: e951e20c4ef6a3f003f84e8f1bea568d1b7ef541)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tar has supported a --checkpoint option since version 1.15.91, so it
should be safe to use here to print dots showing that it's still doing
something (technically it's not really progress unless you know how many
dots it's going to print, which even it doesn't know at the start, but
it's better than nothing).
(From OE-Core rev: ee4aadd179be8141536f2fae16482683855a9a37)
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>
Extensible SDK cannot be installed as root so by default offer to install it in
user's home directory under distro/distro_version replacing the normal SDK
version '+' char with a '_' as that's a restricted character for bitbake
(From OE-Core rev: 5486e76cd8abb946b81cff78719d67cfb87cddc6)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Tell the user how to set up the SDK environment each time they want to
use it.
(From OE-Core rev: 617225af7a7cc9cb038fb1e6466af03867482032)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
If the buildsystem is copied into the sdk and its toolchain is to
be used, then the relocation provided in toolchain-shar-template.sh
isn't needed and will actually fail.
So break the relocation aspect out and essentially make it another
SDK_POST_INSTALL_COMMAND script.
(From OE-Core rev: 9721378688a05cd8d8443c6ee4be823e5c0688f6)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
