diff options
author | Joshua Lock <joshua.g.lock@intel.com> | 2016-09-08 21:49:13 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-09-09 12:06:53 +0100 |
commit | f94ac02f459e2ea0fc471463966997814a67e0ca (patch) | |
tree | fb01da2e3e92e079ae19895e3b84b3f77a6c2311 /scripts/bitbake-prserv-tool | |
parent | 1e8165ea2f19aecdc03ccd102ee44ef0544f0f39 (diff) | |
download | openembedded-core-f94ac02f459e2ea0fc471463966997814a67e0ca.tar.gz openembedded-core-f94ac02f459e2ea0fc471463966997814a67e0ca.tar.bz2 openembedded-core-f94ac02f459e2ea0fc471463966997814a67e0ca.zip |
runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE
testimage.bbclass uses runqemu to execute runtime tests on a qemu
target, this means that bitbake is already running and `bitbake -e`
can't be called to obtain bitbake variables.
runqemu tries to work around being unable to read values for
bitbake variables by inferring the MACHINE from the
DEPLOY_DIR_IMAGE setting, however if a user sets that variable in
a manner which doesn't follow the systems expectations (i.e. if
running `bitbake -c testimage` against a directory of pre-generated
images in a user-specified path) the inferring of the MACHINE name
from the DEPLOY_DIR_IMAGE location will fail.
It's possible that check_arg_machine() shouldn't cause runqemu to
fail and that runqemu should proceed with the user-supplied value
even if it can't be verified. This patch simply ensures that a
workflow where the user sets DEPLOY_DIR_IMAGE continues to work
without changing too much of the runqemu code.
[YOCTO #10238]
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'scripts/bitbake-prserv-tool')
0 files changed, 0 insertions, 0 deletions