(Redirected to the proper lists, excluding emacs-devel.)
Helmut Eller <eller.hel...@gmail.com>:
> > If nobody bothers with even
> > considering the question, it would appear that it is not all that
> > important...
>
> Maybe nobody bothers because using clang is easier than to fight with
> FSF policies.
Which is pretty close if not identical to my original point.
The clang people aren't just a technical challenge to GCC, they're a
philosophical/political one to the FSF as well. They are explicitly
reacting, and positioning themselves publicly against, what they
consider FSF over-control.
The clearest possible statement of this is in Chandler Carruth's talk
"Clang: Defending C++ from Murphy's Million Monkeys" (all over
YouTube) in which he explains "why we set out to build another C++
compiler" by beginning with this question posted to the gcc list: "is
there are reason for not making the [GCC] front ends dynamic
libraries which could be linked by any program that wants to parse
source code?"
Carruth then quotes RMS: "One of our main goals for GCC is to prevent
any parts of it from being used together with non-free software.
Thus, we have deliberately avoided many things that might possibly have
the effect of facilitating such usage..."
Carruth then says, exasperation very obvious in his voice, "This is *not*
a *useful answer*!" (about 3:42 in the video). Thus, the clang project. They
want to build IDEs and other tools that share the compiler's code. GCC
policy won't let them do that. Ergo, GCC must be kicked aside.
The clang developers are demonstrating that they have the capacity to make
good on this threat. clang is not a toy or a laboratory demonstration; it
is a real, production-quality compiler with some significant advantages over
GCC. Much more useful error messages is one; a newer generation of
optimization leading to smaller, tighter code is another; and much faster
compilation is yet another.
The "Clang vs Other Open Source Compilers" page admits that "GCC
supports more targets than LLVM" and "GCC supports languages that
clang does not aim to", but these are not stable advantages given the
technical strength of LLVM and the large amount of developer
commitment clang now has.
I'm not pointing out these facts to argue with the FSF's past decisions,
but to ask "What are you going to do now?"
More of the same will not serve. GCC is in near-term danger of losing
its dominance in open-source C development; I would say the danger is
imminent if not that people are innately conservative about major changes
to their toolchains. The other shoe will drop when a major Linux distribution
ships with clang as its default compiler; I could easily see this happening
before the end of 2015, followed by a cascade of me-too defections.
To keep its #1 spot, GCC needs to out-improve and out-compete clang.
And not just on the technical level, either. "Using clang is easier
than to fight with FSF policies" indeed. Unless that changes, GCC's
future is as a legacy tool, a backwater that developers are exiting
as fast as is practical.
As I've said before, I don't personally care who wins; either tool
will serve my needs. I would prefer to see both flourish and
compete with each other. But that's not where things are heading
unless GCC ups its game.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
