<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><base href="x-msg://5416/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Why not treat it like the current gcc-based approach? The builder generates C and quake invokes the C compiler. Just like for gcc: the builder generates .mc and quake invokes m3cgc1. I will want much the same for LLVM. The builder will generate LLVM IR binaries and the LLVM tools will do the rest (invoked from quake). This makes it relatively easy to do cross builds from quake.<div><div>
<br><div><div>On Oct 12, 2012, at 12:50 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="hmmessage" style="font-size: 12pt; font-family: Calibri; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div dir="ltr">Clarification: it is "integrated" either way -- no production of .mc files.<div>Just that cm3/builder would know that "IntegratedC" produce a .c file (or perhaps is writing to a pipe) and to then run the C compiler. Vs. pushing that into the backend itself and leaving cm3/builder with "IntegratedObject" that it already knows how to deal with. Either way cm3/builder has to change.</div><div><br></div><div><br></div><div>Currently I'm going through config-only changes.</div><div><br></div><div><br></div><div> - Jay</div><div><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>From: <a href="mailto:antony.hosking@gmail.com">antony.hosking@gmail.com</a><br>Subject: Re: [M3devel] C backend -- mode or call quake?<br>Date: Fri, 12 Oct 2012 09:12:53 -0400<br>To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br><br><div>I vote for integrated. <br><br>Sent from my iPhone</div><div><br>On Oct 12, 2012, at 0:43, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div dir="ltr">ok..so..I think time to make this decision and implement it.<div><br></div><div> - add a "mode" for C and deal with it in Builder.m3</div><div> I implemented and tested that and presented the diff a few weeks ago</div><div> It is reasonable, simple, works..but it isn't strictly needed.</div><div><br></div><div>or</div><div><br></div><div>- use IntegratedObject and have the C backend call the C compiler "itself" (via the</div><div>existing quake/config files)</div><div>I can go ahead and implement that.</div><div><br></div><div><br></div><div>Either way, cm3 likely must know about the C backend.</div><div><span style="font-size: 12pt; ">It at least has to "new" it, and maybe pass down function pointers for running</span></div><div><span style="font-size: 12pt; ">the C compiler -- or maybe M3C can get the pointers itself.</span></div><div><span style="font-size: 12pt; "><br></span></div><div>Or I can put this off a bit longer and improve the generated C...</div><div>Using "integrated" saves us from writing and reading back the .mc files.</div><div>More efficient.</div><div><br></div><div><br></div><div><span style="font-size: 12pt; "> - Jay</span></div></div></blockquote></div></div></div></div></blockquote></div><br></div></div></body></html>