From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Thu, 12 Feb 2015 12:22:36 +0100 Message-ID: <87bnkzpe6b.fsf@fencepost.gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <20150208001527.GA30292@thyrsus.com> <20150209150411.1f0f4e4f@jabberwock.cb.piermont.com> <20150211111722.181a2201@jabberwock.cb.piermont.com> <20150211183700.04ec0613@jabberwock.cb.piermont.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1423740186 32308 80.91.229.3 (12 Feb 2015 11:23:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 11:23:06 +0000 (UTC) Cc: esr@thyrsus.com, emacs-devel@gnu.org, Richard Stallman , slewsys@gmail.com, monnier@iro.umontreal.ca To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 12 12:23:01 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 1YLrrH-0000bw-PN for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 12:22:59 +0100 Original-Received: from localhost ([::1]:49626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLrrH-0000Tg-8s for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 06:22:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLrr4-0000Tb-11 for emacs-devel@gnu.org; Thu, 12 Feb 2015 06:22:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLrr2-0007l1-Qa for emacs-devel@gnu.org; Thu, 12 Feb 2015 06:22:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLrr2-0007kx-NA for emacs-devel@gnu.org; Thu, 12 Feb 2015 06:22:44 -0500 Original-Received: from localhost ([127.0.0.1]:54834 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLrqv-0004L3-43; Thu, 12 Feb 2015 06:22:37 -0500 Original-Received: by lola (Postfix, from userid 1000) id AF02BE0D89; Thu, 12 Feb 2015 12:22:36 +0100 (CET) In-Reply-To: <20150211183700.04ec0613@jabberwock.cb.piermont.com> (Perry E. Metzger's message of "Wed, 11 Feb 2015 18:37:00 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:182945 Archived-At: "Perry E. Metzger" writes: > On Wed, 11 Feb 2015 18:13:30 -0500 Richard Stallman > wrote: >> > 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. >>=20 >> If you are talking about outputting ASTs, that has nothing to do >> with how modular GCC is. This is a different issue. > > If this is the case, returning to an earlier issue: > > It might not per se necessary that Emacs have access to the AST in > textual form. If GCC or part of GCC could be called as a library from > within Emacs to access the AST via an API, that might be sufficient. I'm reminded of a talk in a "fuzzy logic" conference I was in at one time. The resume from the authors was more or less that their novel compression method achieved something like 20% of the signal theory theoretical maximum performance, so if they got 10=A0times the funding, they should be able to achieve about 200% of the theoretical maximum. There is a principal basic problem that we cannot overcome with any trickiness: Emacs and GCC are two separate, independent applications. _Any_ way in which we are able to combine them will have a point where Emacs as an application ends and/or a point where GCC ends. At those points, we can swap in a different IDE from Emacs, and a different compiler from GCC, and copyright will not come into play. The GPL is a license based on copyright and nothing else. Any complication we design for combining GCC and Emacs is going to hit the combination GCC/Emacs just as hard as everyone else. > I don't yet have an opinion on whether it would be more or less > convenient than having the AST in some other form, but it would > certainly permit Emacs to have arbitrary access to semantic > information about the program being edited. AST or any other form: the problem will remain identical. What works for the separate applications Emacs and GCC will work equally well with respect to copyright by replacing one of the components. So it is a waste of time thinking up ways to obfuscate the issue. The principal boundary condition of combining GCC and Emacs is that we have two identifiable entities that are separate with regard to their copyright. What works for them, works for other entities with separate copyright. --=20 David Kastrup