[cfe-dev] How clang is seen outside the community (Was: Re: david's integer overflow stuff)

[Douglas Gregor]

On Sep 17, 2010, at 5:14 PM, OvermindDL1 wrote:

> On Fri, Sep 17, 2010 at 4:44 PM, David Chisnall <csdavec at swan.ac.uk> wrote:
>> On 17 Sep 2010, at 23:24, Chris Lattner wrote:
>>> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them.
>> 
>> Because the major negative comment that is raised when I suggest people adopt clang is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers.
> 
> This post from another newsgroup I frequent is somewhat related and
> may give you any idea of a view of clang from outside the clang
> community, but by people that are using it:
> 
> On Yesterday, someone somewhere else wrote:
>> /* snip some */
>> It's become clear to me in the past few days that while Clang excels
>> in many areas, it is stunningly behind in one regard: the distributed
>> driver implementation. Even in a GUI IDE, a programmer's experience
>> with a compiler often revolves around the instantiation of a
>> compilation through the composition of a cryptic string of flags.
>> 
>> Clang, I'm afraid to say, takes the GCC approach in the worst way
>> possible (I can understand that they haven't had time to document all
>> command line options; heck, I'll even give them a pass on having whole
>> groups of "hidden" options. But not even listing the --help-hidden
>> command?). This is done in the name of compatibility with GCC, the
>> existing compiler used in Xcode (the Mac development suite).
>> 
>> This strange, archaic front-end implementation of Clang's otherwise
>> brilliantly organized API will, IMHO, not only discourage its use and
>> extend the longevity of the existing suite of overly complex make
>> systems; it also directly inhibits our ability to implement plugins in
>> Clang, because the clang++ driver does not provide any method for
>> passing arguments to the underlying, collect2-style "clang++ -cc1"
>> binary. Compiling hello world with a plugin (in addition to requiring
>> the plugin to make a callback to the compilation process if it is just
>> an inspector. The currently checked in version of the profiler doesn't
>> do this, yet) ends up looking something like this:
>> 
>> clang++ -cc1 -load ~/test/build/default/Profiler/libarielProfiler.so -
>> plugin test-profiler -triple x86_64-unknown-linux-gnu -S -disable-
>> free -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-
>> elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-
>> linker-version 2.20.51 -resource-dir /usr/local/lib/clang/2.9 -ferror-
>> limit 19 -fmessage-length 179 -fexceptions -fgnu-runtime -fdiagnostics-
>> show-option -fcolor-diagnostics -o foo.s -x c++ foo.cpp
>> 
>> And that's just to get the assembly. You'd then have to invoke the
>> linker on your own (and, as it's expected that the clang++ driver will
>> be doing this, even the slightest mistake will break things).
>> Alternatively, of course, we could modify the driver; but then, those
>> looking to use any of the extensions we might create would have to use
>> our modified driver.
>> 
>> It gets better. Clang does not support DLL plugins (I think someone
>> told me that Clang is not really working much on their plugin system
>> ATM; they're trying to replace the GCC toolchain entirely on Darwin).
>> In addition to the other Windows-related Clang problems /* snip */,
>> the lack of DLL plugin support means that any
>> further work on this Clang extensions would produce software that will
>> be largely unfriendly to the native operating system of most of our
>> target users (E.g. Boost community and C++ template metaprogramming
>> community at large).


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:

	(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.

	(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

		clang++ -load ~/test/build/default/Profiler/libarielProfiler.so -plugin test-profiler foo.cpp

	(3) Extend Clang with a proper plug-in mechanism. The author isn't the only person interested in a plug-in system, but nobody has stepped up to really make it happen. Rather than complain that it's not being worked on, why not fix the core problem? I bet you'd even find some help along the way.


	- Doug