Hello Philip, everyone,
I've prepared a small demo that illustrates my point on the use of
#include<> versus #include"". See the attached tarball.
include-demo/
|-- builddir/
| |-- Makefile
| `-- config.h <-- we want to use this config header...
`-- srcdir/
|-- config.h <-- ...and not this one
|-- hello1.c <-- uses <>
`-- hello2.c <-- uses ""
srcdir/config.h contains an #error directive. Here is what I get, using
GCC:
/tmp/include-demo/builddir$ make
cc -I. ../srcdir/hello1.c -o hello1
cc -I. ../srcdir/hello2.c -o hello2
In file included from ../srcdir/hello2.c:1:
../srcdir/config.h:6:2: error: #error EVIL
make: *** [hello2] Error 1
Notice how hello2 incorrectly picked up srcdir/config.h, instead of
builddir/config.h. #include"" gave priority to the directory containing
the source file, even overriding the -I. directive.
This behavior is fundamentally at odds with the notion of
out-of-source-tree builds, and IMO a compelling argument in favor of
#include<config.h>.
--Daniel
On Sat, 2007 Sep 01 21:05:20 +0100, Philip Hazel wrote:
>
> A look at my (admittedly ancient) C standard doesn't help. It
> essentially says that both <> and "" semantics are implementation
> defined. I myself was previously caught with <> for pcre.h picking up a
> system-installed header rather than the local one - but that was when
> compiling Exim with included PCRE files. There is no -I. there.
