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 <[email protected] > > <mailto:[email protected]>> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
