Re: Why <config.h> and not "config.h" ?

[Óscar Fuentes]

Jan Djärv <address@hidden> 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.