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

I am that other guy. We have fixed our dependency maker in the meantime.
Here is the last state of the previous discussion again:

Regards,
Andreas Kardos
-------------------------

"Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:

OK, but in general it is not usual that a system header includes another
system header with #include "" (from the application programmers point of
view).

I do not intend to break the consistency of the PostgreSQL make system. So
feel free to rollback. But to be consistent you should replace at least the
following includes as well:

ecpglib.h:#include <postgres.h>
ecpglib.h:#include <libpq-fe.h>
ecpglib.h:#include <ecpgerrno.h>

Next week I will discuss the situation with our guy who is responsible for
this dependency maker. He is currently out of town.

Regards,
Andreas Kardos

-----Ursprüngliche Nachricht-----
Von: Tom Lane <tgl@sss.pgh.pa.us>
An: Kardos, Dr. Andreas <kardos@repas-aeg.de>
Cc: Bruce Momjian - CVS <momjian@news.tht.net>;
<pgsql-committers@postgresql.org>
Gesendet: Donnerstag, 23. März 2000 17:49
Betreff: Re: [COMMITTERS] pgsql/src/interfaces/libpq (libpq-fe.h)


> "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> > The reason is: We are using at here for historical reasons our own make
> > system for applications. Our dependency maker assumes that a file must
be in
> > the local source directory if it is included by
> > #include "file"
> > OK, this is a lack of this dependency maker. To solve this (our)
specific
> > problem I must copy or symlink postgres_ext.h to the local source
directory.
>
> Hmm.  So, to cater to a dependency maker that you admit is broken, we
> should change the sources so that they'll generate wrong output on non-
> broken dependency makers?
>
> Since postgres_ext.h hardly ever changes, and probably can't change
> without a system-wide recompile, the lack of a dependency for it isn't
> likely to be real critical.  So I'll let this slide for now.  But if
> someone else complains, I'll change it back ;-).  Consider that you've
> been given a grace period to fix your dependency analyzer.
>
> regards, tom lane
>



-----Ursprüngliche Nachricht-----
Von: Tom Lane <tgl@sss.pgh.pa.us>
An: Didier Verna <didier@xemacs.org>
Cc: <bugs@postgresql.org>; XEmacs beta testers <xemacs-beta@xemacs.org>;
Oliver Elphick <Oliver.Elphick@lfix.co.uk>
Gesendet: Montag, 10. April 2000 21:15
Betreff: Re: [BUGS] #include oddity in v7.0b3


> 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
>