Re: [BUGS] #include oddity in v7.0b3

Tom> Where in the ANSI C spec does it say that #include "" behaves Tom> that way and #include <> doesn't? Where does it even say Tom> that you're allowed to specify a path in #include at all? It Consider X11. The normal procedure is to include via forms like <X11/Xlocale.h>. A compiler that doesn't support that may be ANSI-compliant. I doubt it will be used much, and certainly not for building XEmacs. Tom> seems to me you are treating an implementation choice made by Tom> your compiler as gospel. (Yes, I know gcc behaves that way.) I'll stipulate that you're right about the specs; it is simply the fact that the "detect the path" method is working well for us in other cases. This is the first time it has broken for us because the assumption that "" would find all recursively included headers installed in the same place failed. As for "our compiler", do you mean the HPUX compiler, MS VC++, the AIX compiler, the IRIX compiler, the DEC compiler, Solaris's compiler, or what? Not only does XEmacs build under all those compilers IIRC, but it also builds under at several C++ compilers without changing the code. XEmacs must be built under as many compilers as PostgreSQL. It's probably true that the most-used compiler is GCC. That's why we regularly see patches being rejected, even reversed, for depending on GCCisms. If this is a GCCism, it can be reversed, too. But as far as I know, all compilers used to build XEmacs do includes the way our code expects. That's a lot of compilers! And the current PostgreSQL 7.0b3 setup will break every single one of them as far as XEmacs is concerned. Tom> But I can't see putting much weight on arguments that are Tom> based on a practice as unusual and non-standards-compliant "Portability" means never being able to say "we're standards-compliant." Heck, we build on the MS Windows platform. "Standards? We embrace, extend, and, ultimately, extinguish." 100% compliance is impossible (notwithstanding the foreseeable breakup of Microsoft). The reason we use the method we do is to localize the non-compliant code to a very few well-known places, and only when conditional on the platforms that need it. It's a fact of life for multi-platform applications, as you are arguing yourself (see below), that some platforms will choose to do things differently. Just as you do, we want to support those platforms. We prefer to do so in a way that hides their differences from the main body of source code where possible. We think it improves maintainability. We could use the `-I' method, but who knows what other cruft we'll pick up on some systems? XEmacs _is_ rather unusual in that we currently automatically detect and use nearly a score of add-on capabilities by default, and have several configure options whose default is off, but when "on" also search for and automatically configure perhaps a dozen more. I think that making such versatility maintainable is deserving of your support. Putting in more than 20 `-I's means we cannot guarantee where anything will get included from. We know from past experience that we cannot rely on packages to have their devel support files in sensible places, not even on platforms like Debian which claim strict adherence to a file system standard. Certainly not cross-platform! With short names like "libpq-fe.h" and "drop-in replacement" libraries like Xaw3d as common as they are, we also need to find a way to avoid name collisions on the preprocessor's include path. Our approach allows a flexible response to both unusual locations for devel support files and collisions, without excessively uglifying the source files. I think it is equally arguable that in the real world any subsystem which knows where its headers are but doesn't use that information, and instead relies on `-I' to find them, is broken, since `-I' is broken by design in regard to collisions. There doesn't seem to be an ANSI way of specifying the recursive header location information, but both `"" searches current directory' and `<app-includes/header.h>' as used by X11 seem to work well enough in practice. The `""' approach seems preferable, since it allows for glitches like Debian's renaming of the PostgreSQL application includes directory. But the current PostgreSQL setup doesn't support either of these methods. Tom> as putting full paths directly into #include commands. In But we don't actually use full paths anyway; in the case of PostgreSQL 7.0 under Debian "woody", the path that CPP eventually sees is <postgresql/libpq-fe.h> (by expansion of POSTGRES_INCLUDE(libpq-fe.h); it's done that way so that we don't need to clutter source code with #ifdef's for different systems or remember to munge all source files dealing with a given 3rd-party package: the POSTGRES_INCLUDE macro is defined in one place, src/config.h). In the end, just like X11. And also do note that ./configure has actually located and confirmed the usability of the header file in question. This is not hard-coded; it is autodetected. Tom> the normal context where search paths are driven by -I, it Tom> won't matter which form we use. If that's so, then ... Tom> Give me a better reason, and I'll change it back. But I Tom> don't want to have to explain to the other guy that we're not Tom> going to support his situation just to make the world safe Tom> for an arguably broken coding method, even if it is one used Tom> by a project as big as XEmacs. ... if the _other_ user is using the "search path driven by -I" method, then he _can't_ be broken by supporting our practice according to your argument. I infer _he's_ also doing something "arguably broken." A matter of taste which to support. No? We know our way works simultaneously for several add-on packages and on many compilers. Maybe it or something similar would work for him, too. Personally, I'm not going to be upset if you decide that you are going to treat "" and <> as interchangable in PostgreSQL header files, to support somebody else's brokenness in preference to ours. In practice we can accede to your demand that we treat PostgreSQL specially. I'm just not willing to accept the argument that we're badly broken when all the compilers we buld under seem to support the `"" searches current directory, <> does not (unless specified by -I)' distinction. Our experience is that making this assumption allows us to minimize brokenness subject to localizing brokenness to known places as much as possible. Brokenness exists. Given that, I think our goal of minimizing and localizing it is deserving of your support. I think that it is true that our coding practice improves maintainability, and I hope you will give that due consideration. (Of course in combination with finding some way to support your other client projects.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."