A long time ago (6 years), this seemed like a good idea. The reality is
that OVERRIDES should not be being added to hashes and if it is, it likely
needs excluding in its own right. This was a nice workaround but we need
to fix the real underlying issues now. In some cases this means excluding
OVERRIDES from the variables dependency using the vardepsexclude flag however
caution is needed to ensure this is safe.
Variable values used to construct hashes are unexpanded but the values used
are computed after the application of OVERRIDES. The important detail is if
the end resulting unexpanded value changes, not the value of the OVERRIDES
used in the construction of that unexpanded value. This is why dependencies
on OVERRIDES itself shouldn't be in the hashes in general.
The recent DISTRO_FEATURES changes adding in override mappings for them
highlighted this issue. We have some good sstate tests which are effective
at highlighting where potential issues arrive with OVERRIDES contamination
(oe-selftest -r sstatetests.SStateTests).
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
# 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 = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}${DISTROFEATURESOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
-OVERRIDES[vardepsexclude] = "MACHINEOVERRIDES"
CLASSOVERRIDE ?= "class-target"
DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
MACHINEOVERRIDES ?= "${MACHINE}"
-MACHINEOVERRIDES[vardepsexclude] = "MACHINE"
FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
