Re: #include oddity in v7.0b3

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

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