From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Why <config.h> and not "config.h" ?
Date: Wed, 28 Jul 2010 11:38:05 +0200 [thread overview]
Message-ID: <87pqy8q742.fsf@telefonica.net> (raw)
In-Reply-To: 4C4FE2E8.2030009@swipnet.se
Jan Djärv <jan.h.d@swipnet.se> 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 <config.h> 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
<stdio.h> it can reformat your hard disk and be perfectly
conformant. They write it on a very technical, serious-looking language,
though.
next prev parent reply other threads:[~2010-07-28 9:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 2:23 Why <config.h> and not "config.h" ? Óscar Fuentes
2010-07-28 2:30 ` Miles Bader
2010-07-28 3:25 ` Óscar Fuentes
2010-07-28 6:30 ` Jan Djärv
2010-07-28 6:46 ` Óscar Fuentes
2010-07-28 7:06 ` Jan Djärv
2010-07-28 7:35 ` Óscar Fuentes
2010-07-28 7:57 ` Jan Djärv
2010-07-28 8:04 ` immanuel litzroth
2010-07-28 8:19 ` Jan Djärv
2010-07-28 9:38 ` Óscar Fuentes [this message]
2010-07-28 10:07 ` Óscar Fuentes
2010-07-28 8:29 ` Andreas Schwab
2010-07-28 8:59 ` Óscar Fuentes
2010-07-29 14:26 ` Stefan Monnier
2010-07-30 9:21 ` Stephen J. Turnbull
2010-07-30 9:55 ` Eli Zaretskii
2010-08-01 9:31 ` Stephen J. Turnbull
2010-07-28 7:06 ` Andreas Röhler
2010-07-28 7:10 ` Óscar Fuentes
2010-07-28 7:15 ` Yavor Doganov
2010-07-28 7:46 ` Óscar Fuentes
2010-07-28 19:50 ` Dan Nicolaescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pqy8q742.fsf@telefonica.net \
--to=ofv@wanadoo.es \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.