[Openembedded-architecture] Yocto Compatible 2.0 + signature changes
Patrick Ohly
patrick.ohly at intel.com
Thu May 11 09:48:12 UTC 2017
On Tue, 2017-05-09 at 10:17 +0100, Richard Purdie wrote:
> I'm not saying this is a good idea or that we should do this but I
> suspect it is at least possible:
>
> DISTROOVERRIDES .= "${@bb.utils.contains('DISTRO_FEATURES', 'refkit-firewall', ':refkit-firewall', '', d)}"
I ran into a practical issue with this for native recipes: because
native.bbclass filters out DISTRO_FEATURES unless specifically
whitelisted, the special feature and thus also the override weren't
active for native recipes.
My solution is a .inc file and a helper .bbclass:
.inc file:
DISTROFEATURES2OVERRIDES += " \
refkit-config \
refkit-firewall \
refkit-computervision \
refkit-gateway \
"
INHERIT += "distrooverrides"
distrooverrides.bbclass:
# Turns certain DISTRO_FEATURES into overrides of the same name
# or (optionally) some other name. 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_foobar () { ... }
# where "foobar" is an optional DISTRO_FEATURE.
#
# TODO: is renaming useful? It makes the code more complex and potentially slower (untested).
DISTROFEATURES2OVERRIDES ?= ""
DISTROFEATURES2OVERRIDES[doc] = "A space-separated list of <feature>[=<override>] entries. \
Each entry is added to DISTROOVERRIDES with the <feature> name or the optional <override> name, \
but only when <feature> is in DISTRO_FEATURES."
DISTROOVERRIDES_FEATURES = "${@ ' '.join([x.split('=', 1)[0] for x in d.getVar('DISTROFEATURES2OVERRIDES').split()]) }"
DISTRO_FEATURES_FILTER_NATIVE_append = " ${DISTROOVERRIDES_FEATURES}"
DISTRO_FEATURES_FILTER_NATIVESDK_append = " ${DISTROOVERRIDES_FEATURES}"
DISTROOVERRIDES .= "${@ ''.join([':' + (x.split('=')[1] if '=' in x else x) for x in d.getVar('DISTROFEATURES2OVERRIDES').split() if bb.utils.contains('DISTRO_FEATURES', x.split('=', 1)[0], True, False, d)]) }"
What do others think about this? Is the renaming aspect useful enough to
justify the extra complexity? If we agree on the override approach, this
probably should go to OE-core, together with general documentation about
making a layer "Yocto 2.0 Compatible".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the Openembedded-architecture
mailing list