Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

"Eric S. Raymond" <address@hidden> writes:

> Richard Stallman <address@hidden>:
>> More precisely, Apple intends LLVM and Clang to make GCC cease to be a
>> signal success and a reason for all sorts of companies to work on a
>> compiler that always gives users freedom.
>
> This is silly.  Apple couldn't care less whether or not GCC is a
> success.  What Apple needs is for a copylefted compiler not to be the
> *only* success.

Apple does not really need that: they did not break a leg when they had
to open their Objective C frontend for GCC.  But it's not like that has
led to an overboarding Objective C Free Software community.  What Apple
was forced to give back did not end up being of much interest to us, and
I think GCC has stopped building ObjC support by default.

> GCC's existence does not prevent Apple from compiling proprietary GPU
> code.  The absence of a realistic *alternative* to GCC prevented that,
> but having fixed that problem Apple has no reason to care whether GCC
> lives or dies.
>
> As David Kastrup notes, the existence of the clang project is victory
> - it's Apple conceding in practice that it is no longer realistically
> possible to develop some kinds of critically important tools in a
> proprietary lockup.

It's not victory: there is no victory without actual winners and losers.
And I don't see a concession of Apple either.  Their support for
Clang/LLVM did not start in a vacuum: those projects were live before
Apple decided to support them.  They decided not to mess with that basic
setup.  That this decision made sense: that is a vindication of free
software.  But that's not a victory over Apple or a concession of them.

> As a result of this victory, all sorts of companies are now working on
> *two* compilers that always give users freedom.  One is GCC.  The
> other is clang (I haven't noticed my freedom being diminished even a
> little bit when I set CC=clang). That is a good thing.

Several companies will not work on more than one compiler, and the
decision which compiler to work on will mainly determined by the ease of
working with and on the compiler.  That, in turn, is determined by
architectural differences, but in the case of GCC, it is now also
determined by shifting policies for the sake of interfering with
interoperability.

I find little surprise in companies preferring a platform where these
considerations are not an issue.  After all, the whole point of those
policies is to hit usability where it hurts.  Otherwise they would be
ineffective.

And in general there is nothing wrong with GCC or Emacs being
unpalatable for purposes at crossroads with free software.  That's the
whole point of the GPL as well.  The problem is that GCC and Emacs
become unpalatable for purposes compatible with free software's goals as
well.

> Apple is not composed of angels.  Apple does things that you and I
> would both regard as scummy.  But to suppose that Apple has any
> desire, need, or intention to attack GCC is to attribute an importance
> to GCC in Apple's eyes that it has not possessed since the day clang
> shipped 1.0.

I'm not sure about Apple's intentions at all.  But I don't think we
should be doing their job of persuading people to move away from GCC and
Emacs because they cannot be relied upon as an interoperable tool.

-- 
David Kastrup