[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