As I am also rather surprised by this perception, here is my perspective leading a team external to Apple doing exactly this -- building user-facing tools on top of Clang:<br><br><div class="gmail_quote">On Fri, Sep 17, 2010 at 5:49 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@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 id=":4kv">I have no idea where this came from, but there are several ways to accomplish the task that the author alludes to (extending Clang to build their own tool) that are better than what s/he's describing:<br>

<br>
        (1) Use Clang's Frontend library with their own driver or UI, so s/he has total control over the interface, whether it be different command-line arguments or something with checkboxes. Toggling bits in ClangInvocation would work perfectly fine.<br>
</div></blockquote><div><br></div><div>Yep. We have tools that do this, many of them in fact. The APIs have rough edges, but they work well. We've had great success here.</div><div><br></div><div>Ironically, a large enabler for us was the ability to re-use the exact aspect of Clang that is being complained about -- GCC flag compatible parsing. Our tools work hard to co-exist with GCC flags and usages which are very prevalent, and being able to at a moments notice drop down and ask Clang to parse a set of GCC or Clang flags was incredibly useful.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":4kv">       (2) Teach Clang's driver to pass -load and -plugin through to -cc1. A few minutes of coding eliminates the entire problem of having to think about -cc1. Users would just use something like<br>
</div></blockquote><div><br></div><div>Doesn't "clang++ -Xclang -plugin -Xclang ..." work today? Maybe that's "too gross"...</div></div>