A belated reply...<br><br><div class="gmail_quote">On Fri, Mar 27, 2009 at 4:39 PM, Mike Stump <span dir="ltr"><<a href="mailto:mrs@apple.com">mrs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mar 27, 2009, at 1:54 PM, Chris Lattner wrote:<br>
> Then why did you work against that plan by making clang-cc smarter?<br>
<br>
</div>My solution lies exactly on the path to that end.  If you test clang-<br>
cc, you'll discover it behaves exactly like gcc with regard to this<br>
option and that clang, when it is ready to suck up all of clang-cc,<br>
can just suck up these bits unmodified.  </blockquote><div> </div><div><snip></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
here, notice that there is a minimum of translation happening in the<br>
driver, this is desirable, as it means that there is zero work to do<br>
post sucking up all of clang-cc into clang.</blockquote><div><br></div><div>While I understand your theory; this is the opposite of the direction we want to be going in. clang isn't going to "suck up" clang-cc by handing off an argument vector which we pass to the LLVM command line library, clang is going to want to build up nice API calls into the Frontend library.</div>
<div><br></div><div>Towards that end (and the direction we have been headed), the idea is to make clang do the *maximum* of translation, and have clang-cc be as direct and obvious as possible. For example, clang-cc should not need to compute path names, figure out the output mode, the input language, the target triple, and so on.</div>
<div><br></div><div>Right now the driver doesn't have a lot of extra support for argument translation, but this is something we can build up gradually as the need arises. I was thinking maybe a custom language embedded in string constants... :)</div>
<div> </div><div> - Daniel</div><div><br></div></div>