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

[Alexander Kanavin]

On 11/10/2015 04:31 PM, Mark Hatle wrote:
> Is there a way that the qemu calls can be replaced by calls to an actual running
> board (via SSH perhaps) to get the necessary information?  While inconvenient
> this might be a valid workaround.

Theoretically, yes. Copy the sysroot and the build tree to the board (to 
some safe location, obviously), then execute the arch-dependent bits of 
the process remotely, then copy the output files back. Slow, but doable. 
The executable wrapper mechanism for that is already provided by the 
patchset.

I would however first seriously look into reengineering g-o so that it's 
architecture-independent, and doesn't require such awful contortions. 
Primarily, two things:
1) It should be easy to build transient introspection binaries for the 
native architecture, instead of building them for the target together 
with the rest of the package. Those binaries produce textual output 
(essentially a list of classes/signals/properties) which is 
architecture-independent.
2) The binary introspection database in .typelib files should not be a 
raw dump of a C structure, and should be actually the same on all 
architectures.

> Also is there any facility to caching the gobject responses (other then standard
> sstate-cache) so for machine that do not have QEMU support we can used a cached
> set of responses?  (I'm not sure if these responses could be considered to be a
> global cache, or if they are distribution specific in configuration.  Likely the
> later.)

This requires custom bitbake support I'm afraid, a specialist needs to 
answer this.



Alex