The eSDK generation assumes that DL_DIR is downloads/ under the build directory,
and puts files such as a freshly buily uninative tarball in there expecting
bitbake will find it later.

Whilst ${TOPDIR}/downloads/ is in fact the default value for DL_DIR in
bitbake.conf, and any instances of DL_DIR are removed from the original
local.conf, there is still the possibility that other layers could contain a
site.conf that assigns DL_DIR.

If this happens the errors are quite mysterious as it fails to find the
uninative tarball and so the hashes all change, and eSDK building fails.

Ensure that this cannot happen by explicitly assigning the DL_DIR that we
require, instead of assuming that the default value will be used.

[ YOCTO #10439 ]

Signed-off-by: Ross Burton <ross.burton@intel.com>

The Yocto Project Eclipse plugin requires that runqemu and unfsd are
accessible within the SDK, and indeed the standard SDK has these. This
turns out to be fairly easy to do - we just need to add unfsd and symlink
it, runqemu and a few other scripts into the SDK's bin directory.

Fixes [YOCTO #10214].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

After we run the build system within the eSDK internally as part of the
sstate filtering that happens during do_populate_sdk_ext, we need to
ensure that the TMPDIR created during that process gets deleted. However
we were using the TMPDIR path for the build producing the eSDK which may
not be the same (since that value would typically be filtered out) thus
if the user had set TMPDIR to something other than the default, the
temporary TMPDIR would not be deleted which not only led to extraneous
junk entering the SDK but also failures during install because the
TMPDIR path was different. In order to fix this, force TMPDIR to a known
value during the sstate filtering run so we know what to delete
afterwards.

Fixes [YOCTO #10210].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Tasks for image recipes cannot be locked and should be excluded from eSDK
generated locked-sigs.inc. get_sdk_install_targets() was not returning right
image targets to be excluded incase of 'minimal' sdk. This change fixes the issue.

Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Adding populate_sdk task to SSTATE_TASKS should make sstate machinery
to generate manifest for deployed ext sdk artifacts and do final deployment
to SDK_DEPLOY.

This is done in a similar way to do_populate_sdk in a previous patch.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adding populate_sdk task to SSTATE_TASKS should make sstate machinery
to generate manifest for deployed sdk artifacts and do final deployment
to SDK_DEPLOY.

Set stamp-extra-info flag for do_populate_sdk task. This flag is used
in the name of sstate manifest. Setting it to predetermined value for
populate_sdk task should help to get correct manifest filenames when
processing runQueueTask events.

The do_populate_sdk function is also executed by do_populate_sdk_ext
so in order to avoid conflicts with the sstate postfuncs, split
the main code into a separate function.

We also need to set SDKDEPLOYDIR as do_populate_sdk_ext expects
it in order not to break ESDK generation.

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The preparation script itself prints out an error on failure, and we
aren't redirecting its output anymore, so we no longer need to print out
a message here when it fails. At the same time, make the message printed
out by the script a little clearer - we're just writing the log out to
the file, we shouldn't give the user an expectation that there will be
extra details in there (other than the output produced by
oe-init-build-env there won't be).

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Check a number of things as early as possible in the eSDK installer
script so that the user gets an error up front rather than waiting for
the build system to be extracted and then have the error produced:

* Check for missing utilities specified in SANITY_REQUIRED_UTILITIES
  (along with gcc and g++), taking into account that some of these are
  satisfied by buildtools which ships as part of the SDK. We use the
  newly added capability to list an SDK's contents to allow us to see
  exactly which binaries are inside the buildtools installer.
* Check that Python is available (since the buildtools installer's
  relocate script is written in Python).
* Check that locale value set by the script is actually available
* Check that the install path is not on NFS

This does duplicate some of the checks in sanity.bbclass but it's
difficult to avoid that given that here they have to be written in shell
and there they are written in Python, as well as the fact that we only
need to run some of the checks here and not all (i.e. the ones that
relate to the host system or install path, and not those that check the
configuration or metadata). Given those issues and the fact that the
amount of code is fairly small I elected to just re-implement the checks
here.

Fixes [YOCTO #8657].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Determine the name of the current buildtools installer ahead of time,
set it in a variable and use that variable rather than the wildcarded
version everywhere, since it's much tidier.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

If the buildtools installation failed, we were using a subshell instead
of a compound command and thus the subshell exited but the script
continued on, which is really not what we want to happen. Additionally
log the buildtools installer output to a file and cat it if it fails so
that you can actually see what went wrong, as well as amending the
environment setup script to print a warning as we do when the
preparation fails.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>