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

Richard Purdie richard.purdie at linuxfoundation.org
Thu Apr 11 19:59:58 UTC 2019


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



More information about the Openembedded-core mailing list