classes/populate_sdk_ext: handle lack of uninative when filtering sstate

If the build in which the eSDK is being built isn't using uninative,
this will have an effect on NATIVELSBSTRING, which will mean that the
eSDK installer won't be able to find any of the native sstate packages.
To keep things simple, under this scenario just disable uninative
temporarily while we run the SDK installer to help us check the presence
of the sstate artifacts we need. Ideally I'd rather not have things like
this that are artificial in this verification step, but on the other
hand this was the least ugly way to solve the problem.

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

1 files changed, 5 insertions, 0 deletions

diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass
index f758d9874e..c16e228e7e 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -108,9 +108,14 @@ def create_filtered_tasklist(d, sdkbasepath, tasklistfile, conf_initpath):
     # Create a temporary build directory that we can pass to the env setup script
     shutil.copyfile(sdkbasepath + '/conf/local.conf', sdkbasepath + '/conf/local.conf.bak')
     try:
+        # Force the use of sstate from the build system
         with open(sdkbasepath + '/conf/local.conf', 'a') as f:
             f.write('\nSSTATE_DIR_forcevariable = "%s"\n' % d.getVar('SSTATE_DIR', True))
             f.write('SSTATE_MIRRORS_forcevariable = ""\n')
+            # Drop uninative if the build isn't using it (or else NATIVELSBSTRING will
+            # be different and we won't be able to find our native sstate)
+            if not bb.data.inherits_class('uninative', d):
+                f.write('INHERIT_remove = "uninative"\n')
 
         # Unfortunately the default SDKPATH (or even a custom value) may contain characters that bitbake
         # will not allow in its COREBASE path, so we need to rename the directory temporarily