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: Mon, 9 Feb 2015 15:04:11 -0500 Message-ID: <20150209150411.1f0f4e4f@jabberwock.cb.piermont.com> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <20150208001527.GA30292@thyrsus.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 1423512264 26436 80.91.229.3 (9 Feb 2015 20:04:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 20:04:24 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org, Richard Stallman , slewsys@gmail.com, Stefan Monnier To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 09 21:04:23 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 1YKuZD-0006tN-2d for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 21:04:23 +0100 Original-Received: from localhost ([::1]:34964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKuZC-00062r-BV for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 15:04:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKuZ8-00062h-Lf for emacs-devel@gnu.org; Mon, 09 Feb 2015 15:04:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKuZ7-0004IR-H2 for emacs-devel@gnu.org; Mon, 09 Feb 2015 15:04:18 -0500 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:35547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKuZ3-0004Dr-37; Mon, 09 Feb 2015 15:04:13 -0500 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 6FBD584; Mon, 9 Feb 2015 15:04:12 -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 288832DEEAB; Mon, 9 Feb 2015 15:04:12 -0500 (EST) In-Reply-To: <20150208001527.GA30292@thyrsus.com> 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:182736 Archived-At: On Sat, 7 Feb 2015 19:15:27 -0500 "Eric S. Raymond" wrote: > Richard Stallman : > > 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. I should like to correct a partial misperception here. I don't think Apple's main motivation was to have a proprietary compiler. On a purely technical level, LLVM makes lots of things possible that Apple needed that GCC does not allow. LLVM, for example, interfaces well to IDEs and refactoring tools, which Apple needed, and now has built into XCode -- though note that the support on the LLVM side is in the free software LLVM tree and is in no way proprietary, and free software IDEs can make full use of those interfaces. For another example, LLVM is modular so it is possible to use it in producing static analysis tools, which Apple needed, and are now built -- but again those analysis tools are in the free software LLVM tree, not in a proprietary Apple tree, and may be modified and incorporated into free software projects. LLVM was created in academia, not by Apple, and it was specifically a response to the fact that academics working on language tool and compiler research simply couldn't manage to use GCC to get their work done. They wanted to do research on things like static analysis tools, code transformation tools, link-time optimization, JITs, etc., and GCC deliberately makes it hard to use its pieces in such projects, so they needed to build their own. I myself use LLVM and not GCC for my academic research, which is because my work is too difficult to do in GCC and very easy to do under LLVM. 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. I think the lesson we can all draw is that architectural decisions made for political strategy reasons are of limited utility. Eventually, code designed for technical superiority will become more popular than code with features missing for "strategic reasons". If you want the more popular code to be free software, and if you want it to be GPLed software, then you must assure that your alternative is technically as good as it can be and suits the needs of its users as well as it can. As I understand it, the goal of making GCC non-modular was to prevent the use of GCC to write proprietary front and back ends that do not link directly to GCC. However, if GCC had been modular, it would have been the focus of all the academic research, and all the tools built on top would have been linked against GCC and thus would also have been GPLed. In addition, Dragon Egg demonstrated that GCC could be used as the front end to an LLVM compiler in spite of the strategy. Also in addition, the non-modularity has not prevented the creation of top quality proprietary front and back ends anyway, since they can now be based on LLVM, which is arguably technically superior to GCC at this point anyway and which permits that without much trouble. So again, I think if technical merit had been picked over "strategic considerations", the strategic considerations would have been better served. Perry -- Perry E. Metzger perry@piermont.com