From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Why and not "config.h" ? Date: Wed, 28 Jul 2010 11:38:05 +0200 Message-ID: <87pqy8q742.fsf@telefonica.net> 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> <4C4FE2E8.2030009@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1280311744 11035 80.91.229.12 (28 Jul 2010 10:09:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 28 Jul 2010 10:09:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 28 12:09:03 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 1Oe3ZP-0002wm-0k for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 12:09:03 +0200 Original-Received: from localhost ([127.0.0.1]:56671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oe3ZO-0008H8-5k for ged-emacs-devel@m.gmane.org; Wed, 28 Jul 2010 06:09:02 -0400 Original-Received: from [140.186.70.92] (port=44692 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oe3Wy-00078I-Sy for emacs-devel@gnu.org; Wed, 28 Jul 2010 06:06:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oe3K9-00056Y-9c for emacs-devel@gnu.org; Wed, 28 Jul 2010 05:53:18 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:45619) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oe3K8-00056J-Rz for emacs-devel@gnu.org; Wed, 28 Jul 2010 05:53:17 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Oe35Z-0003tp-Kr for emacs-devel@gnu.org; Wed, 28 Jul 2010 11:38:13 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jul 2010 11:38:13 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Jul 2010 11:38:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:cvz0xIxzyWoE10wKAy8b9uPTLHY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:127928 Archived-At: Jan Djärv writes: [snip] > As I said, it is a feature not having to run make bootstrap in every > build tree. I usually have five of them (Gtk, Lucid, Motif/Lesstif, > X, no-X). I see that it can save lots of compile time, but it is not a safe practice. [snip] > No, I don't think you are making up things, there are a lot of buggy > tools out there. But which tools are we going to make this change > for? Are they free and generally useful for all developers? Most > analysis tools I've used does not have any problem with <> and "". > You usually can pass -I. to them if that is needed. In this case, the tool is CMake. I'm not sure if it is a bug or a feature, I've asked about that on their ml. People used to complain about the time required for checking depedencies on large projects (this is specially aggravating on Windows) and maybe they decided headers included with <>, which usually are external to the project. It seems a bit extreme to me, but may be. IIRC some tools of the style of the late SourceNavigator have switches for not diving into headers included with <>, which is very convenient as today a simple #include can bring in tens of thousands of LoC from some big library. Yesterday I had an issue with MinGW using a build specification that worked fine on GNU/Linux and, on addition, was formally correct. Through some intermediate steps, the compiler ended picking up src/process.h instead of mingw/include/process.h. Replacing with "config.h" fixed the problem. [snip] > No, it does not. The search for include files with <> does not start > in the current directory, where as for "" it does. That is the only > difference. If the headers are system headers or not is not the > difference. With <> the search does not start on the current directory for avoiding collisions with the headers there. That means that the "external" headers take precedence. You can call it system headers or library headers, but the intention is that they do not belong to the set of source files being compiled at the moment. However, I agree with you that it is convenience, nor stylistic theory, what matters here. As an anecdote, I'll say that, as others mentioned, what <> means is implementation-dependant. Long time ago this issue arised on the Borland newsgroups because some user discovered the hard way that their compiler had slightly different rules from GCC. After some minutes reading the C++ standard it was clear that when the compiler finds #include it can reformat your hard disk and be perfectly conformant. They write it on a very technical, serious-looking language, though.