From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?SmFuIERqw6Rydg==?= Newsgroups: gmane.emacs.devel Subject: Re: Why and not "config.h" ? Date: Wed, 28 Jul 2010 09:57:28 +0200 Message-ID: <4C4FE2E8.2030009@swipnet.se> References: <87wrsgs5t3.fsf@telefonica.net> <87y6cwz6bq.fsf@catnip.gol.com> <87sk34s2ws.fsf@telefonica.net> <4C4FCE87.4090600@swipnet.se> <87iq40rtn3.fsf@telefonica.net> <4C4FD6FD.1020105@swipnet.se> <878w4wrrde.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1280303864 16679 80.91.229.12 (28 Jul 2010 07:57:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Jul 2010 07:57:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?B?w5NzY2FyIEZ1ZW50ZXM=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 28 09:57:41 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oe1WG-0006sD-TV for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 09:57:41 +0200 Original-Received: from localhost ([127.0.0.1]:52066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oe1WG-0004YM-8J for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 03:57:40 -0400 Original-Received: from [140.186.70.92] (port=51559 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oe1W9-0004Y7-Dj for emacs-devel@gnu.org; Wed, 28 Jul 2010 03:57:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oe1W8-0004Fg-1m for emacs-devel@gnu.org; Wed, 28 Jul 2010 03:57:33 -0400 Original-Received: from smtprelay-b11.telenor.se ([62.127.194.20]:50224) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oe1W7-0004FG-K9 for emacs-devel@gnu.org; Wed, 28 Jul 2010 03:57:32 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id 13CEBE9630 for ; Wed, 28 Jul 2010 09:57:29 +0200 (CEST) X-SENDER-IP: [85.225.45.35] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aro3ACKAT0xV4S0jPGdsb2JhbACDFIRSmAQMAQEBATUtrieRVIEmgx1zBA X-IronPort-AV: E=Sophos;i="4.55,272,1278280800"; d="scan'208";a="111648229" Original-Received: from c-232de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.35]) by ipb1.telenor.se with ESMTP; 28 Jul 2010 09:57:29 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id EEEE67FA05A; Wed, 28 Jul 2010 09:57:28 +0200 (CEST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 In-Reply-To: <878w4wrrde.fsf@telefonica.net> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127920 Archived-At: 2010-07-28 09:35, =C3=93scar Fuentes skrev: > Jan Dj=C3=A4rv writes: > >>> As explained above, if the .elc files are corrupted by a buggy Emacs = or >>> a buggy Emacs ends using healthy .elc files, by sharing the produced >>> .elc/.el files among several builds you are hiding a bug. Mixing the >>> products of different builds is never a good idea. >> >> Didn't you read what I wrote? Out-of-tree builds use the *SAME* elc >> files, those located in the tree. Adding another out-of-tree build >> does not remake the elc-files. That is one of the strong reasons to >> use out-of -tree builds for different configurations. > > Yes, I read what you wrote. It seems that you are not trying to > understand what I say, though. > > The fact that several builds share the same .elc files is, precisely, a > potential source of problems. If you can't see that, well, lucky you, > because then it is clear that you never experienced a problem caused by > a setup like that. As I said, it is a feature not having to run make bootstrap in every buil= d=20 tree. I usually have five of them (Gtk, Lucid, Motif/Lesstif, X, no-X). > >> BTW, I used Emacs for more than 20 years and have yet to see a >> corrupted elc-file. > > Corrupted in any sense? Is the byte compiler so robust that it never > miscompiled an .el file on 20 years? No, I read on this list of bytecompiler errors from time to time. They s= eem=20 to be few and far between though. I haven't experienced it though. > >>>> Considering that<> enables a real use-case and "" does not, and th= e >>>> fact that using "" gives exactly no benefits what so ever, please >>>> stick to<>. It is not even less to type. I can't imagine any reaso= n >>>> for switching now. >>> >>> Maybe is my hideous English, but as explained on my original message<= > >>> is giving me problems with some tool. >> >> Some code analysis tools is too vague. > > Are you suggesting that I'm making up the issue? Or maybe the issue is > irrelevant to you because it doesn't affect the tools you use? No, I don't think you are making up things, there are a lot of buggy tool= s out=20 there. But which tools are we going to make this change for? Are they f= ree=20 and generally useful for all developers? Most analysis tools I've used d= oes=20 not have any problem with <> and "". You usually can pass -I. to them if= that=20 is needed. > >> We are building Emacs right now out-of-tree. > > No, you are building on a mixed setup, both out of tree and in-tree. > Yes, but not from the same source tree. However, I do from time to time=20 migrate from in-tree to out-tree. > Anyways, if you are building out of tree, there is no problem with the > change because, as Miles explained, the angle brackets are used > precisely for supporting simultaneous out of tree and in-tree > builds. Removing the angle brackets is no problem for simultaneous out > of tree builds. And having them there is no problem either. > >> If you are going to impose a change on that process again just after >> it was changed recently, you have to come up with something better >> than that. > > Here we go again. No matter how small is the change one proposes, > somebody will extract terrible cosequences from it, or refuse to > evaluate the benefits dismissing it as useless, or both. Motivating a change to cater for some broken analysis tool isn't terribly= =20 convincing too me. And, as pointed out, autoconf recommends <>. > >> As for the gcc thing, that is intentional, it is how it is >> supposed to work. > > Yes, I know, I was caught there. AFAIK the algorithm used by GCC assume= s > that angle brackets are for system headers. > No, it does not. The search for include files with <> does not start in = the=20 current directory, where as for "" it does. That is the only difference.= If=20 the headers are system headers or not is not the difference. Jan D.