summaryrefslogtreecommitdiffstats
path: root/meta/classes/distrooverrides.bbclass
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2017-06-14 12:33:50 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2017-06-14 14:45:01 +0100
commite982ca7f2d4fb0aef3fedc00af1e90f613e7b5ee (patch)
treefd4fe1659f1d723d7ee71ae273a11f8e6a623176 /meta/classes/distrooverrides.bbclass
parent0c6e4a14ba8d9d9701ec16ffe46d618f41633571 (diff)
downloadopenembedded-core-e982ca7f2d4fb0aef3fedc00af1e90f613e7b5ee.tar.gz
distrooverrides.bbclass: DISTRO_FEATURES as overrides
This achieves the same goal as the same change to bitbake.conf itself, but because the class gets added later as part expanding INHERIT, this new approach is less likely to run into problems when DISTRO_FEATURES contains complex code. Another difference is that the class currently does not get inherited by default and thus is completely absent from a build unless some layer or include file adds it to INHERIT. Compared to the earlier code in bitbake.conf and a similar class in intel-iot-refkit, additional overrides now get sorted. This makes the final OVERRIDES more deterministic. The lessons learned about unintentionally depending on OVERRIDES are documented in the class because such problems are more likely to show up as unexpected signature differences when using this class. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/distrooverrides.bbclass')
-rw-r--r--meta/classes/distrooverrides.bbclass32
1 files changed, 32 insertions, 0 deletions
diff --git a/meta/classes/distrooverrides.bbclass b/meta/classes/distrooverrides.bbclass
new file mode 100644
index 0000000000..9a42712f20
--- /dev/null
+++ b/meta/classes/distrooverrides.bbclass
@@ -0,0 +1,32 @@
+# Turns certain DISTRO_FEATURES into overrides with the same
+# name plus a df- prefix. Ensures that these special
+# distro features remain set also for native and nativesdk
+# recipes, so that these overrides can also be used there.
+#
+# This makes it simpler to write .bbappends that only change the
+# task signatures of the recipe if the change is really enabled,
+# for example with:
+# do_install_append_df-my-feature () { ... }
+# where "my-feature" is a DISTRO_FEATURE.
+#
+# The class is meant to be used in a layer.conf or distro
+# .inc file with:
+# INHERIT += "distrooverrides"
+# DISTRO_FEATURES_OVERRIDES += "my-feature"
+#
+# Beware that this part of OVERRIDES changes during parsing, so usage
+# of these overrides should be limited to .bb and .bbappend files,
+# because then DISTRO_FEATURES is final.
+
+DISTRO_FEATURE_OVERRIDES ?= ""
+DISTRO_FEATURE_OVERRIDES[doc] = "A space-separated list of <feature> entries. \
+Each entry is added to OVERRIDES as df-<feature> if <feature> is in DISTRO_FEATURES."
+
+DISTRO_FEATURES_FILTER_NATIVE_append = " ${DISTRO_FEATURES_OVERRIDES}"
+DISTRO_FEATURES_FILTER_NATIVESDK_append = " ${DISTRO_FEATURES_OVERRIDES}"
+
+# If DISTRO_FEATURES_OVERRIDES or DISTRO_FEATURES show up in a task
+# signature because of this line, then the task dependency on
+# OVERRIDES itself should be fixed. Excluding these two variables
+# with DISTROOVERRIDES[vardepsexclude] would just work around the problem.
+DISTROOVERRIDES .= "${@ ''.join([':df-' + x for x in sorted(set(d.getVar('DISTRO_FEATURES_OVERRIDES').split()) & set((d.getVar('DISTRO_FEATURES') or '').split()))]) }"