[meta-xilinx] [PATCH 2/2] zynqmp-pmu.bbclass: Fix issues with zynqmp-pmu and multilib

[Nathan Rossi]

When using multilib the MULTILIB_VARIANTS variable is populated, this
triggers differing code paths in certain recipes. These are not desired
for the firmware building, since they modify the install paths.

Also set the DEFAULTTUNE to avoid changes to BASELIB/baselib when
multilib is used, as it attempts to set BASELIB based on 'tune-*'
overrides.

Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
---
 classes/zynqmp-pmu.bbclass | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/classes/zynqmp-pmu.bbclass b/classes/zynqmp-pmu.bbclass
index 3ebe48813e..714eb96a77 100644
--- a/classes/zynqmp-pmu.bbclass
+++ b/classes/zynqmp-pmu.bbclass
@@ -16,6 +16,7 @@
 ORIG_TARGET_ARCH := "${TARGET_ARCH}"
 
 # zynqmp-pmu target arch (hardcoded based on pre-gen data from arch-microblaze.inc)
+DEFAULTTUNE = "microblaze"
 ABIEXTENSION = ""
 TUNE_ARCH = "microblazeel"
 #TUNE_FEATURES_tune-microblaze += "v9.2 barrel-shift pattern-compare"
@@ -65,6 +66,9 @@ python multitarget_zynqmp_pmu_virtclass_handler () {
     e.data.setVar("MLPREFIX", variant + "-")
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-" + variant)
 
+    # hide multilib variants, this class is not one but this works around recipes thinking it is (due to MLPREFIX).
+    e.data.setVar("MULTILIB_VARIANTS", "")
+
     # work around for -cross recipes that embed the TARGET_ARCH value
     if bb.data.inherits_class('cross', e.data):
         if initialpn.endswith("-" + d.getVar("ORIG_TARGET_ARCH")):
-- 
2.14.1