[OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

[Richard Purdie]

On Tue, 2015-11-10 at 12:25 -0600, Mark Hatle wrote:
> On 11/10/15 11:40 AM, Burton, Ross wrote:
> > 
> > On 10 November 2015 at 16:39, Mark Hatle <mark.hatle at windriver.com
> > <mailto:mark.hatle at windriver.com>> wrote:
> > 
> >     Let me rephrase.  Instead of calling out to qemu (or a real target) for a
> >     gobject and result.  Can the result be cached (like we do with the config-site
> >     info?)  This would allow me to run say a MIPS64 n64 gobject build, cache the
> >     results and use it on my octeon3 build (which can't run in QEMU.)
> > 
> > 
> > The metadata contains stuff like type sizes and alignment but wouldn't it be
> > possible to have some sort of map from machine to close-enough qemu machine?  So
> > for octeon3 is qemumips64 is close enough, run that.
> > 
> > (to be honest I thought the qemu runner support as used by the postinsts already
> > did this)
> 
> That would work in many cases.. the problem is that it requires "yet another"
> sysroot or whatnot to be able to build the runner.
> 
> (I think QEMU supports pretty much all of the major, and some minor
> architectures these days... it just doesn't support many of the semi-specific
> optimizations.)

As I understand it, there are at least two ways we could solve this:

a) build a native version of the recipe and run that to get the
introspection data
b) cache the introspection data and reuse it

There are obviously advantages and disadvantages to each but as I
understand it the data is architecture independent.

Using qemu is the least ugly from a build performance impact though
without getting into cache problems.

Cheers,

Richard