On 11/10/15 9:36 AM, Alexander Kanavin wrote: > 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.
I don't disagree with you there... > 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. > 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.) --Mark > > Alex > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
