On 10.03.2016 01:15, Richard Purdie wrote: > On Thu, 2016-03-10 at 01:09 +0100, Martin Jansa wrote: >> On Thu, Mar 10, 2016 at 12:52:20AM +0100, Andreas Oberritter wrote: >>> Hello Alexander, >>> >>> On 09.03.2016 16:01, Alexander Kanavin wrote: >>>> Signed-off-by: Alexander Kanavin < >>>> [email protected]> >>>> --- >>>> meta/classes/gobject-introspection.bbclass | 39 >>>> ++++++++++++++++++++++++++++++ >>>> 1 file changed, 39 insertions(+) >>>> create mode 100644 meta/classes/gobject-introspection.bbclass >>>> >>>> diff --git a/meta/classes/gobject-introspection.bbclass >>>> b/meta/classes/gobject-introspection.bbclass >>>> new file mode 100644 >>>> index 0000000..ef51629 >>>> --- /dev/null >>>> +++ b/meta/classes/gobject-introspection.bbclass >>>> @@ -0,0 +1,39 @@ >>>> +# Inherit this class in recipes to enable building their >>>> introspection files >>>> + >>>> +# This allows disabling introspection support in recipes >>>> +# (and therefore avoiding the use of qemu) >>>> +# if gobject-introspection-data is omitted from DISTRO_FEATURES >>>> and MACHINE_FEATURES. >>>> +EXTRA_OECONF_prepend = "${@bb.utils.contains('COMBINED_FEATURES' >>>> , 'gobject-introspection-data', '--enable-introspection', '- >>>> -disable-introspection', d)} " >>> >>> testing only DISTRO_FEATURES would be better. If MACHINE_FEATURES >>> gets >>> tested, even though indirectly, I'd expect every recipe inheriting >>> this >>> class to switch to MACHINE_ARCH implicitly. >> >> I think the idea was to prevent using qemu for MACHINEs without >> support >> in qemu. But I fully agree that causing all recipes which inherit >> this >> bbclass effectively MACHINE_ARCH is even worse. >> >> DISTRO needs to make sure that all supported MACHINEs have support in >> qemu or disable introspection for all of them. > > Remember that bitbake has special knowledge of bb.utils.contains() and > is clever enough to make the checksums depend on "gobject-introspection > -data" being present or not and not the actual complete value. > > So we can get the best of both worlds here, you can disable g-i on a > per machine basis yet still enable at the distro level. Recipes don't > become machine specific.
How does this work out on a shared package feed, of which some machines have the required qemu support and others don't? Regards, Andreas -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
