[OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner

[Alexander Kanavin]

Yes, I agree.

Alex

> On 11 Apr 2019, at 21.59, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
>> On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote:
>>> On 4/11/19 10:35 AM, Alexander Kanavin wrote:
>>> On Thu, 11 Apr 2019 at 17:25, Jason Wessel <
>>> jason.wessel at windriver.com> wrote:
>>>>> Generally because generating introspection data is disabled for
>>>>> native
>>>>> packages, as a matter of policy (do not build something which
>>>>> is
>>>>> unused and untested).
>>>>> 
>>>>> If you could add
>>>>> EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
>>>>> 
>>>>> to the gdk-pixbuf recipe, and re-test (without your fix, to be
>>>>> extra
>>>>> sure) that g-ir-scanner is not invoked and nothing shows up in
>>>>> its
>>>>> cache, I would appreciate.
>>>> 
>>>> Thank you for the explanation.  I think the problem is more
>>>> widespread than just gdk-pixbuf, now that I have a slightly
>>>> better idea about what we are looking for.  My build is not even
>>>> complete and I can see there are three additional places the g-
>>>> ir-scanner is creating .cache entries.
>>>> 
>>>> /poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp
>>>> |awk -F/ '{print $4}' |sort -u
>>>> atk-native
>>>> at-spi2-core-native
>>>> pango-native
>>>> 
>>>> 
>>>> Is it the case the bbclass file should be altered to set this
>>>> variable for the -native, or does each package need to be
>>>> modified individually?
>>> 
>>> I think Andreas's patchset that was recently posted (and is
>>> currently
>>> in master-next) takes care of this in a general way, where you
>>> don't
>>> have to go and fix every recipe. The unfortunate bit is that meson
>>> does not have a standard flag for enabling/disabling introspection,
>>> but we found a way to deal with this that is as generic as
>>> possible.
>>> 
>>> If you try with master-next, would be good to know.
>>> 
>> 
>> It all appears to work fine without the need to patch anything in
>> master-next.  
>> 
>> Thank you for the explanation.
> 
> This is starting to look like something we probably want to pull into
> the warrior release given the problems with meson converted recipes
> otherwise?
> 
> Cheers,
> 
> Richard
>