[cfe-commits] r67863 - in /cfe/trunk: include/clang/Driver/Options.def tools/clang-cc/clang.cpp

[Daniel Dunbar]

A belated reply...

On Fri, Mar 27, 2009 at 4:39 PM, Mike Stump <mrs at apple.com> wrote:

> On Mar 27, 2009, at 1:54 PM, Chris Lattner wrote:
> > Then why did you work against that plan by making clang-cc smarter?
>
> My solution lies exactly on the path to that end.  If you test clang-
> cc, you'll discover it behaves exactly like gcc with regard to this
> option and that clang, when it is ready to suck up all of clang-cc,
> can just suck up these bits unmodified.


<snip>

here, notice that there is a minimum of translation happening in the
> driver, this is desirable, as it means that there is zero work to do
> post sucking up all of clang-cc into clang.


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.

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.

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... :)

 - Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090407/5e0ce851/attachment.html>