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:53:58 +0100
commit38184d391b5224b261805696864d5d8109645f81 (patch)
tree75e05659c159d84d67eb01677370cec599448d17 /meta/classes/distrooverrides.bbclass
parenta83dc5b11373c418a855c6e50601732396e3185a (diff)
downloadpoky-38184d391b5224b261805696864d5d8109645f81.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. (From OE-Core rev: e982ca7f2d4fb0aef3fedc00af1e90f613e7b5ee) 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 @@
1# Turns certain DISTRO_FEATURES into overrides with the same
2# name plus a df- prefix. Ensures that these special
3# distro features remain set also for native and nativesdk
4# recipes, so that these overrides can also be used there.
5#
6# This makes it simpler to write .bbappends that only change the
7# task signatures of the recipe if the change is really enabled,
8# for example with:
9# do_install_append_df-my-feature () { ... }
10# where "my-feature" is a DISTRO_FEATURE.
11#
12# The class is meant to be used in a layer.conf or distro
13# .inc file with:
14# INHERIT += "distrooverrides"
15# DISTRO_FEATURES_OVERRIDES += "my-feature"
16#
17# Beware that this part of OVERRIDES changes during parsing, so usage
18# of these overrides should be limited to .bb and .bbappend files,
19# because then DISTRO_FEATURES is final.
20
21DISTRO_FEATURE_OVERRIDES ?= ""
22DISTRO_FEATURE_OVERRIDES[doc] = "A space-separated list of <feature> entries. \
23Each entry is added to OVERRIDES as df-<feature> if <feature> is in DISTRO_FEATURES."
24
25DISTRO_FEATURES_FILTER_NATIVE_append = " ${DISTRO_FEATURES_OVERRIDES}"
26DISTRO_FEATURES_FILTER_NATIVESDK_append = " ${DISTRO_FEATURES_OVERRIDES}"
27
28# If DISTRO_FEATURES_OVERRIDES or DISTRO_FEATURES show up in a task
29# signature because of this line, then the task dependency on
30# OVERRIDES itself should be fixed. Excluding these two variables
31# with DISTROOVERRIDES[vardepsexclude] would just work around the problem.
32DISTROOVERRIDES .= "${@ ''.join([':df-' + x for x in sorted(set(d.getVar('DISTRO_FEATURES_OVERRIDES').split()) & set((d.getVar('DISTRO_FEATURES') or '').split()))]) }"