<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 10 November 2015 at 16:39, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":62f" class="a3s" style="overflow:hidden">Let me rephrase. Instead of calling out to qemu (or a real target) for a<br>
gobject and result. Can the result be cached (like we do with the config-site<br>
info?) This would allow me to run say a MIPS64 n64 gobject build, cache the<br>
results and use it on my octeon3 build (which can't run in QEMU.)</div></blockquote></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(to be honest I thought the qemu runner support as used by the postinsts already did this)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>