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

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

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