Re: #include oddity in v7.0b3

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

Please tell me M. Lane, what makes you react so aggressively ?

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

C'mon. This is pure and simple bad faith. Postgresql itself has
examples of using "" and <>, and paths in inclusion macros. Don't get me wrong
on this: all XEmacs strictly requires to compile is an ANSI C compiler.

> It seems to me you are treating an implementation choice made by your
> compiler as gospel. (Yes, I know gcc behaves that way.)

*your* compiler ? XEmacs compiles on Suns, PCs (Unix and Windows),
HPs, SGIs, DECs with gcc but native compilers also. That makes a lot of
platforms. On all of these platforms, the preprocessor works the way the ANSI
C spec doesn't specify. Geeze, if we follow your reasoning, one couldn't even
compile the simplest X11 application.

> I should make it clear that I agree with you: include "" makes more
> sense than include <> in this context,

That's surprising to hear, to say the least.

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

I'm sorry about this, I should have made it clearer. It's not full
path actually. On my debian woody system, it expands to:

#include <postgresql/libpq-fe.h>

just like you would

#include <X11/Intrinsic.h>

and _this doesn't work anymore_.

> In the normal context where search paths are driven by -I, it won't matter
> which form we use.

The context you're talking about is not more "normal" than any other.
-I is broken by concept in many respects. But the most important is that
dozens of -I on the command line is actually not portable because command
lines too long can break some systems. Standards are a good think, but we're
concerned by portability first.

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

"The other guy" for sure must do something as broken as we do. The
size of XEmacs has nothing to do with this.

Tom, let me make this clear: we support many different packages
differently installed on different platforms. We always try to be as compliant
as possible with the standards, and write tricks for very special cases only.
When such tricks are needed, we hide them as much as possible (most of the
time under the form of a configure test and one or two macros). The way we
include `libpq-fe.h' (see above) is not unusual at all. Currently, *only*
postgres 7.0 breaks this scheme. That sounds to me as a good enough reason.

One more thing: I was trying to have a constructive discussion with
you. We could perfectly well make a special case for postgresql. No problem.
We do that already for soooo many broken stuff that we support. However, my
policy has always been to try to try first to cooperate with external software
developers before writing tricks. I don't know if something was wrong in my
english wording, but I must say that in this context, I'm rather upset by your
reaction.

--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier(at)lrde(dot)epita(dot)fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99