Tom Lane <tgl(a)sss.pgh.pa.us&gt; wrote: Please tell me M. Lane, what makes you react so aggressively ? 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. *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. That's surprising to hear, to say the least. 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_. 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. "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＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99