The bulk of the work in allarch recipes happens in handlers because the
finer details of how the recipe is configured varies. Specifically,
multilib recipes cannot be allarch and if multilib is enabled, the
packages are still tune-specific.
However, this means that recipes that are marked as allarch don't have
INHIBIT_DEFAULT_DEPS set in multilib environments, which is a problem
if it was being used to avoid dependency cycles.
Instead of assigning it at runtime if the recipe really does become
arch-independent, move the assignment from make_arch_independent() to
allarch.bbclass (the other caller in dummy-sdk-package.inc already sets
this). This means that recipes inheriting allarch always have
INHIBIT_DEFAULT_DEPS set.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
# This class is used for architecture independent recipes/data files (usually scripts)
#
+# No need for virtual/libc or a cross compiler
+INHIBIT_DEFAULT_DEPS = "1"
+
python allarch_package_arch_handler () {
if bb.data.inherits_class("native", d) or bb.data.inherits_class("nativesdk", d) \
or bb.data.inherits_class("crosssdk", d):
# Used by allarch recipes and other cases where arch independence is needed
#
def make_arch_independent(d):
- # No need for virtual/libc or a cross compiler
- d.setVar("INHIBIT_DEFAULT_DEPS","1")
-
# Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
# naming anyway
d.setVar("baselib", "lib")