emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enabling company-capf support in cfengine.el


From: John Yates
Subject: Re: enabling company-capf support in cfengine.el
Date: Sun, 19 Jan 2014 21:39:53 -0500

On Sun, Jan 19, 2014 at 9:14 PM, Stephen J. Turnbull <address@hidden> wrote:

He has no objection to clang (or LLVM) itself, because it *is* free
software.  However, the GNU Project sets higher standards, and Emacs
(and GCC) try to conform to them.  Specifically, *defending* freedom,
including *shutting the door* on cooperation with non-free software:

    Do you mean, [gcc-xml outputs] the entire parse tree in full
    detail?
    Would it be conceivable to feed this into a nonfree back-end?
    Would this mean that nonfree backends could take advantage
    of our free front-ends?

That cat already seems to be out of the bag: http://dragonegg.llvm.org/

    If so, it is very dangerous -- it would open the door to a
    terrible setback for our defense of users' freedom.  Namely, the
    use of free software as part of compilers that are partly nonfree.
    I don't remember, but I would guess that is why we have refused to
    merge it into GCC.

    LLVM and Clang open the door to the same terrible setback.  Since
    they are not copylefted, their front-ends can be used with nonfree
    back-ends and vice versa.  [from the cited thread]

So his objection is to emission of information that could be
conveniently used by non-free software to integrate free software into
a non-free toolchain.  AIUI, this is basically the same configuration
that led to the confrontation with Steve Jobs over Objective-C, except
that if the output of the compiler front-end is part of the spec, you
would have almost no leverage in court to claim that it's a single
Work which is a derivative of the copyleft front-end.

RMS may have an inflated sense of the extent to which the greater compiler community (those developing and those using compilers) value gcc over clang / llvm.  For many reason the latter is winning the day.  Speed, memory footprint, modularity, ease of entry, size of development community all favor clang / llvm.  Anecdotal evidence: my startup (Gnu / Linux based product) has just switched from gcc to clang.

/john


reply via email to

[Prev in Thread] Current Thread [Next in Thread]