aboutsummaryrefslogtreecommitdiffstats
path: root/conf/bitbake.conf
diff options
context:
space:
mode:
authorChris Larson <chris_larson@mentor.com>2010-10-15 05:41:21 +0000
committerChris Larson <chris_larson@mentor.com>2010-10-15 12:35:38 -0700
commit5b485324c2ac637e9fc6d40753ee64fd6907db69 (patch)
treee9602027b98fd49630f2590c38efe0ec3a145bd6 /conf/bitbake.conf
parentfd40911b324beebb82cf70f576d3149f8e5e1605 (diff)
downloadopenembedded-5b485324c2ac637e9fc6d40753ee64fd6907db69.tar.gz
Reverse the order of OVERRIDES
Given the current implementation of OVERRIDES in bitbake, the variable is expected to contain elements in the order least specific to most specific, however, our current usage of it does not match that. As one example, "local" is supposed to always be the most specific override, yet currently it's the least specific. As another example, currently the target architecture is seen as more specific than the machine, which is also clearly wrong. Big thanks to Chase Maupin for investigating and identifying this long standing issue. It becomes clear that a reversal of the current value will bring us to a more sane behavior, and avoids the need for the dual overrides hack mentioned in the comments, so this implements this reversal, and drops the unnecessary and confusing comments. This also introduces a MACHINE_OVERRIDES variable as a generic mechanism to inject overrides elements which are more specific than the distro but less specific than the machine, which is where things like MACHINE_CLASS or SOC_FAMILY or the like would go. This variable is *space* separated, to make it easier and more convenient to assemble the variable incrementally. Reported-by: Chase Maupin <chase.maupin@ti.com> Signed-off-by: Chris Larson <chris_larson@mentor.com> Acked-by: Chase Maupin <chase.maupin@ti.com> Acked-by: Khem Raj <raj.khem@gmail.com>
Diffstat (limited to 'conf/bitbake.conf')
-rw-r--r--conf/bitbake.conf17
1 files changed, 3 insertions, 14 deletions
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 494e14e243..c2359dce97 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -675,20 +675,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
# Overrides are processed left to right, so the ones that are named later take precedence.
# You generally want them to go from least to most specific.
-#
-# This means that an envionment variable named '<foo>_arm' overrides an
-# environment variable '<foo>' (when ${TARGET_ARCH} is arm).
-# an environment variable '<foo>_ramses' overrides '<foo>' but doesn't override
-# '<foo>_arm' when ${MACHINE} is 'ramses'.
-# If you use combination ie '<foo>_arm_ramses', then '<foo>_arm_ramses' will override
-# '<foo>_arm' and then '<foo>' will be overriden with that value from '<foo>_arm'.
-# And finally '<foo>_local' overrides anything, but with lowest priority.
-#
-# This works for functions as well, they are really just environment variables.
-# Default OVERRIDES to make compilation fail fast in case of build system misconfiguration.
-OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
-# Alternative OVERRIDES definition without "fail fast", usually only for native building and Scratchbox toolchains.
-#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}"
+MACHINE_OVERRIDES ?= ""
+OVERRIDES = "pn-${PN}:fail-fast:build-${BUILD_OS}:${TARGET_ARCH}:${TARGET_OS}:\
+${DISTRO}:${@':'.join(d.getVar('MACHINE_OVERRIDES', True).split())}:${MACHINE}:local"
##################################################################
# Include the rest of the config files.