From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Wed, 11 Feb 2015 11:17:22 -0500 Message-ID: <20150211111722.181a2201@jabberwock.cb.piermont.com> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <20150208001527.GA30292@thyrsus.com> <20150209150411.1f0f4e4f@jabberwock.cb.piermont.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1423671476 5709 80.91.229.3 (11 Feb 2015 16:17:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 16:17:56 +0000 (UTC) Cc: esr@thyrsus.com, dak@gnu.org, monnier@iro.umontreal.ca, slewsys@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 11 17:17:51 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLZz3-0007fq-Aa for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 17:17:49 +0100 Original-Received: from localhost ([::1]:45753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZz2-0002eU-M5 for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 11:17:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZym-0002eE-3C for emacs-devel@gnu.org; Wed, 11 Feb 2015 11:17:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLZyi-0000vW-0K for emacs-devel@gnu.org; Wed, 11 Feb 2015 11:17:32 -0500 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:43278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLZyd-0000uO-E2; Wed, 11 Feb 2015 11:17:23 -0500 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 0034A657; Wed, 11 Feb 2015 11:17:22 -0500 (EST) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id AF01E2DEF02; Wed, 11 Feb 2015 11:17:22 -0500 (EST) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 166.84.7.14 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182901 Archived-At: On Tue, 10 Feb 2015 17:49:48 -0500 Richard Stallman wrote: > > So to reiterate: LLVM was created because of GCC's deliberately > > non-modular, non-reusable architecture, and not because GCC > > was GPLed. The fact that LLVM is not GPLed and permits > > proprietary forks is a side effect of the history (and > > potentially a very bad one) but was not what caused LLVM to > > come about to begin with. > > That is true. However, the issue for us is the effects of LLVM, > not its motivation. Perhaps I am mistaken, but it *appears* you have characterized LLVM as a deliberate attempt to destroy particular works (such as GCC) of the Free Software Foundation. I was presenting evidence that no such deliberation existed in the design. Similarly, you characterized LLDB as a deliberate attempt to undermine GDB, not merely as something with the possible effect of undermining it. If I'm mistaking what you said, please do inform me, I would prefer not to be mischaracterizing your position. > > So to reiterate: LLVM was created because of GCC's deliberately > > non-modular, non-reusable architecture, > > That is not so. I made GCC as modular as I could. But I believe you have asked in the interim that GCC not be made more modular out of fear of proprietary reuse of the front or back end. This has the effect of interfering with re-use of the code even when it is linked directly in to GPLed tools like Emacs. Was that not the substance of the recent argument about Emacs and completion via GCC, in which you requested more time to consider the issue? > There is one thing I tried to discourage, many years later: > separating the front end and the back end into different > processes. You're supposed to link the back end with the front end. Generally, LLVM also operates as a single executable. It is true that, for convenience, its intermediate representation may be presented as text, as a high density binary format ("bitcode"), or as internal data structures, but the latter is what is generally used to pass things around since it avoids lots of input and output. The distinction here, of course, is that LLVM does not *require* that you link the components together, or indeed, that you use them as a compiler at all. It provides a lot of APIs -- indeed, all of LLVMs components are libraries with a thin wrapper that hooks them together. For example, LLVM permits you to link the front end Clang parser directly into your code for various purposes, including to provide things like AST access for IDEs. Now, if GCC permitted such access, since GCCs code is GPLed, presumably resultant software would also be GPLed, but if I am not mistaken you do not seem very keen on permitting that for fear that people would then build executables that separated compiler passes. Thus, I think we can state that LLVM is more modular than GCC, and not because of technical reasons but because of a strategic political decision. Am I deeply mistaken here? > Designing modules to link together does not mean they are > non-modular. I am afraid that I'm having trouble seeing what the ultimate distinction is -- again, LLVM all links together too. People can do things like building static analysis tools to find bugs in their C and C++ code using LLVM, but they cannot do that with GCC even though they would be linking to GCC's code because there was a fear that excess access would lead to things like proprietary front and back ends. People can do things like building intelligent IDEs using LLVM, but cannot do things like linking GCC's code into Emacs and allowing for building high quality refactoring IDEs out of the combination because of this fear. So, yes, GCC is, so far as I can tell, deliberately made more difficult to use in tools in this manner by policy. If I'm deeply mistaken, please correct me, but I thought that was the whole substance of the recent discussion about AST access from GCC in Emacs. > In 1988 it didn't occur to me that anyone would ever think of doing > that. It would be too slow. I took for granted that the front end > and back end would link together, and wrote them for that. It is now 27 years later. People are willing to alter GCC to be as modular as LLVM is I believe, but I also think you do not want that, so I'm not sure discussing the initial architecture is entirely germane. That said, again, if I am misapprehending your intent, forgive me, and I would be very pleased to know what you actually intend. -- Perry E. Metzger perry@piermont.com