[OE-core] [PATCH 06/24] gobject-introspection.bbclass: add a class that enables gobject introspection

[Andreas Oberritter]

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 <
>>>> alexander.kanavin at linux.intel.com>
>>>> ---
>>>>  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