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: Emacs contributions, C and Lisp Date: Fri, 21 Feb 2014 00:53:12 +0100 Message-ID: <8761o9jq8n.fsf@fencepost.gnu.org> References: <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> 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 1392940407 32242 80.91.229.3 (20 Feb 2014 23:53:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Feb 2014 23:53:27 +0000 (UTC) Cc: Emacs developers , Dmitry Gutov To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 21 00:53:35 2014 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 1WGdQs-00039b-K6 for ged-emacs-devel@m.gmane.org; Fri, 21 Feb 2014 00:53:34 +0100 Original-Received: from localhost ([::1]:41345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGdQs-0000jY-AG for ged-emacs-devel@m.gmane.org; Thu, 20 Feb 2014 18:53:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGdQm-0000jT-2n for emacs-devel@gnu.org; Thu, 20 Feb 2014 18:53:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGdQh-00045i-49 for emacs-devel@gnu.org; Thu, 20 Feb 2014 18:53:28 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGdQh-00045e-0n for emacs-devel@gnu.org; Thu, 20 Feb 2014 18:53:23 -0500 Original-Received: from localhost ([127.0.0.1]:54570 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGdQX-0000uO-FX; Thu, 20 Feb 2014 18:53:13 -0500 Original-Received: by lola (Postfix, from userid 1000) id 03677E8A80; Fri, 21 Feb 2014 00:53:13 +0100 (CET) In-Reply-To: (John Yates's message of "Thu, 20 Feb 2014 18:12:53 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.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:169795 Archived-At: John Yates writes: > I would like to hear the gcc developers weigh in on whether such a tool > (namely a variant invocation of gcc running through all of its lexing, > parsing and semantic analysis) could ever be made to operate at speeds th= at > would make gcc-based completion tolerable. My guess is that switching off optimization, you'd not be all that bad. > This goes to a crucial part of the discussion that I feel RMS fails to > acknowlege. "Fails to acknowledge" is not the same as "is not going to accept". > Namely that clang is not a compiler frontend per se but a set of > performance-focused components targeted at building C++-aware (often > interactive) tools. clang-based completion is not an invocation of a > compiler built by grafting clang onto llvm but rather communication > with a caching server built using clang components. > > We have existence proof that one can use clang libraries to build a > C++ compiler competing with gcc. Well, given the right article author. If we are talking about the conclusions of Phoronix, see . > I wonder how realistic it is to expect gcc to be turned into > components enabling construction of tools similar to those using > clang: > > http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1RefactoringTool.ht= ml > http://clang-analyzer.llvm.org/ > https://code.google.com/p/include-what-you-use/ > > To what extent does the "do not offer interfaces that might enable > repurposing of gcc code for non-free projects" make it unlikely that > such components might ever emerge? Well, GNU offers awk, sed, ed, bash, cat, cut, paste, sort, tac, ptx, bison, gcc itself and a number of other tools that can be used to build and/or plug together proprietary applications from free components. There are also specialized tools like idutils that are explicitly intended to extract and provide program data. And while it would be cumbersome to extract, it would be possible to compile with -O0 -ggdb and get a lot of type info in the object file. So there is quite a bit of precedence: this question is not a black&white one but needs to get answered by weighing advantages and disadvantages. Splitting parser and code generator into separately usable components that can be considered independent would allow using GNU frontends with proprietary backends for selected processors/coprocessors without causing the "software as a whole" clause to trigger. Or proprietary frontends (like the Objective C compiler once was) with the code generator of GCC. Allowing for either of these use cases is giving up a lot of control over derivatives that is the principal motivation for the GPL. The disadvantage of that has to be weighed against the advantages. Even when that has been done, one still has to do an actual implementation and _then_ have to see whether under the constraints of the current implementation the hoped-for advantages are actually as envisioned, and the accepted drawbacks don't turn out larger than expected. And there is not much of an option to turn back the clock, either. In practice, there is not all that much willingness to do an open-minded and open-ended investigation and accept the conclusions either way. I=A0don't exactly blame Richard for not being eager to open a can of worms that is causing enough of a nuisance already while the lid is on. --=20 David Kastrup