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

[Chris Lattner]

This is more appropriate for cfe-dev, where you also posted this.

-Chris

On Sep 17, 2010, at 4:22 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 am not sure which of these thoughts are accurate or not, but I have
> heard similar things from others as well.  My experience with the
> large amount of command parameters is similar to the above, but my
> preferred C++ compiler would be one that compiles to a sqlite database
> or something, and an entire 'project', source files and all (along
> with probably the already tokanized code and other things) would all
> be in such a single sqlite database, but ah, a dream...
> 
> 
> P.S.  And yes, the broken mailserv headers here are also oddly *still*
> different from the other 30+ mailing lists I frequent now.  :)
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev