Re: #include oddity in v7.0b3 - Mailing list pgsql-bugs

Didier Verna <didier@xemacs.org> writes:
>         Obviously, we're smarter than that. I had simplified the
> example to point at the problem clearly. Since we've already
> encountered different possible locations for postgresql headers, we
> actually detect their location at configure time, #define a macro
> containing the path, and use something like #include
> <THE_PATH/the_file.h> (this is yet simplified, but that's the idea).

The usual way to do this is to detect the location and then add a -I
switch to your compile switches.  But I suppose XEmacs is smarter than
every other project on the planet.

>         But that's not the point. When an application has to include a single
> header from a library, and when this application knows where to find it, it
> should be able to include it directly without special cpp cooking. That's why
> headers installed in the same place should use "" and not <> to #include each
> others.

Where in the ANSI C spec does it say that #include "" behaves that way
and #include <> doesn't?  Where does it even say that you're allowed to
specify a path in #include at all?  It seems to me you are treating an
implementation choice made by your compiler as gospel.  (Yes, I know gcc
behaves that way.)

>         The only valid reason for this change I can see is that
> libpq-fe.h and postgres_ext.h could happen to be installed at
> different locations. Can this be the case ?

That is the case at build time, for example.  I think the previous
complainer was unhappy about what his compiler did (or maybe what his
makefile dependency generator did) while building one of the other
Postgres interface libraries or executables that depend on libpq.
Unfortunately the details seem to have vanished into the mailing list
lossages we had last month.

I should make it clear that I agree with you: include "" makes more
sense than include <> in this context, and IIRC I argued against
changing it at the time.  But I can't see putting much weight on
arguments that are based on a practice as unusual and non-standards-
compliant as putting full paths directly into #include commands.
In the normal context where search paths are driven by -I, it won't
matter which form we use.

Give me a better reason, and I'll change it back.  But I don't want
to have to explain to the other guy that we're not going to support
his situation just to make the world safe for an arguably broken
coding method, even if it is one used by a project as big as XEmacs.

            regards, tom lane