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

[Mark Hatle]

On 11/11/15 6:45 AM, Alexander Kanavin wrote:
> On 11/10/2015 06:39 PM, Mark Hatle wrote:
> 
>>> This requires custom bitbake support I'm afraid, a specialist needs to
>>> answer this.
>>>
>>
>> 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 results in this case are .typelib files. They are raw dumps of a C 
> structure in memory - different compilers may produce different binary 
> representations of those. I wouldn't trust that they are the same and 
> that it's okay to copy them around like this. What makes you confident 
> that they are?

For the same architecture (i.e. MIPS64) and the same ABI (n64), the resulting
data structures, packing and similar should all be standard.  Only the generated
instructions and execution order would/could change.

So you would need a way to generate, cache, store the results by arch/abi combo
in order to do this.  The issue of course is that you would need to declare the
arch and abi -- the tune files are the natural place to do this (we really are
declaring it there ANYWAY), and the tune features in many cases may have already
done this...

Something to consider -- the alternative is the dual object (one generic
[arch/abi], one optimized for the tune) that can be used to run on QEMU.  Twice
the compile time but should work fine.


Also has anyone looked at the .typelib information and determined if any of it
is available via direct inspection via readelf, dwarf interpretation or other
method that does not require execution?  Is there a definition of the .typelib
information anywhere and some simple examples of how its generated by the
runtime objects?  (To pursue this, the way forward is to determine a way to
generate the .typelib by reading the chosen binaries in some way -- and then
running a 'ptest' like check that the generated and runtime versions result in
the same data.)

--Mark

> 
> Alex
>