[cfe-dev] 'llvmc --clang' vs. 'ccc'

[Mikhail Glushenkov]

Hi Daniel,

> (2) I don't agree that much of my current work is duplication of
> functionality already present in llvmc. 

I didn't look into it closely, so I won't argue.

> A significant part of my work
> was trying to find an architecture which was "as clean as possible"
> while allowing high gcc compatibility (including, for example,
> integrating the Apple driver driver). I think most of my time has been
> spent solving problems llvmc hasn't dealt with yet; for example, llvmc
> uses LLVM's command line library to parse arguments, but this is
> fundamentally different from how gcc handles arguments.

llvmc also strives to be a drop-in gcc replacement, and I think that
CommandLine is sufficient for that. What isn't possible to do with
CommandLine is cl.exe simulation; this is something we'll definitely
want to tackle at some point in the future. Support for fat binaries
is also on my TODO list.

> [...] the
> ability to be completely independent of the gcc driver (e.g., call cc1
> directly).

This is certainly possible to do with llvmc, it was just easier to
reuse the gcc driver.

> In the end, I hope that we converge to a single full featured driver,
> but for the time being my goal was to get a highly functional driver
> up and running as quickly as possible, and my judgement call was our
> priorities are different enough that it made sense to implement a
> separate tool.

OK, I see your point. If llvmc will benefit from your work, then it's
all for the better. I just think that llvmc's clang plugin needs more
feedback from its target audience, that's all.