Thread

#include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-10T16:40:43Z

[ Cc'ed to the XEmacs development list and the postgres debian package
  maintainer ]

                Hi!

        After upgrading my debian system (woody), the postgres package went
from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located
under /usr/include/postgresql/.

        The file `libpq-fe.h' #include's the file `postgres_ext.h' using <>
instead of "" (line 27). As a consequence, applications that just do:

| #include <full/path/to/libpq-fe.h>

can't build anymore because the file `postgres_ext.h' is not in the path. This
happens to be the case for XEmacs. I believe this is a bug because:

1/ this didn't happen with my former version 6.5
2/ the usage of <> or "" doesn't seem to be coherent among the headers
3/ it's better to use "" when headers installed in the same place have to
   include each others


        What do you think ? Was this change intentional ?

Thanks.

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

Re: #include oddity in v7.0b3

Tom Lane <tgl@sss.pgh.pa.us> — 2000-04-10T17:45:39Z

Didier Verna <didier@xemacs.org> writes:
>         The file `libpq-fe.h' #include's the file `postgres_ext.h' using <>
> instead of "" (line 27). As a consequence, applications that just do:
> | #include <full/path/to/libpq-fe.h>

> can't build anymore because the file `postgres_ext.h' is not in the path.

>         What do you think ? Was this change intentional ?

It was.  Someone else complained that the other way didn't work for them.
At least from the point of libpq, I think they were right.

Offhand, if you do not put -I into your compile switches, I'd be
somewhat surprised that either way would work for you.  Certainly
hardcoding a full path into application source code is a completely
unportable way to do things...

			regards, tom lane

Re: #include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-10T18:07:05Z

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> >         What do you think ? Was this change intentional ?
> 
> It was.  Someone else complained that the other way didn't work for them.
> At least from the point of libpq, I think they were right.

        I don't understand why. Could you explain ?


> Certainly hardcoding a full path into application source code is a
> completely unportable way to do things...

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

        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.

        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 ?

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

Re: #include oddity in v7.0b3

Olivier Galibert <galibert@xemacs.org> — 2000-04-10T18:22:39Z

On Mon, Apr 10, 2000 at 01:45:39PM -0400, Tom Lane wrote:
> Offhand, if you do not put -I into your compile switches, I'd be
> somewhat surprised that either way would work for you.  Certainly
> hardcoding a full path into application source code is a completely
> unportable way to do things...

Not when it's autoconf that does the hardcoding :-)

With the number of external librairies we use, the amount of -I was
becoming a bit too high for our tastes...

  OG.

Re: #include oddity in v7.0b3

Tom Lane <tgl@sss.pgh.pa.us> — 2000-04-10T19:15:58Z

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

Re: #include oddity in v7.0b3

Oliver Elphick <olly@lfix.co.uk> — 2000-04-10T20:42:06Z

Didier Verna wrote:
  >
  >[ Cc'ed to the XEmacs development list and the postgres debian package
  >  maintainer ]
  >
  >                Hi!
  >
  >        After upgrading my debian system (woody), the postgres package went
  >from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located
  >under /usr/include/postgresql/.
  >
  >        The file `libpq-fe.h' #include's the file `postgres_ext.h' using <>
  >instead of "" (line 27). As a consequence, applications that just do:
  >
  >| #include <full/path/to/libpq-fe.h>
  >
  >can't build anymore because the file `postgres_ext.h' is not in the path. Th
      >is
  >happens to be the case for XEmacs. I believe this is a bug because:
  >
  >1/ this didn't happen with my former version 6.5
  >2/ the usage of <> or "" doesn't seem to be coherent among the headers
  >3/ it's better to use "" when headers installed in the same place have to
  >   include each others

The Debian documentation used to include a statement that
`-I/usr/include/postgresql' should be included in the compilation options.
That seems to have got lost.


-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "But seek ye first the kingdom of God, and his  
      righteousness; and all these things shall be added  
      unto you."     Matthew 6:33

Re: #include oddity in v7.0b3

Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> — 2000-04-11T07:00:58Z

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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."

Re: #include oddity in v7.0b3

Kardos, Dr. Andreas <kardos@repas-aeg.de> — 2000-04-11T07:49:22Z

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
>

Re: #include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-11T08:40:56Z

Tom Lane <tgl@sss.pgh.pa.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@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

Re: #include oddity in v7.0b3

Peter Eisentraut <e99re41@docs.uu.se> — 2000-04-11T11:10:48Z

On Tue, 11 Apr 2000, Stephen J. Turnbull wrote:

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

The way I see it, the only thing you can reasonably assume is that given
#include <foo> (where "foo" is any string) the compiler will try to
consider a file XXXfoo, for each XXX in the search path for include files
(which is partially hard-coded into the compiler and partially controlled
by setting -I or similar options and may or may not include the current
directory, or the directory the containing file is in). You cannot assume
that "" does anything differently than <>. The difference is cosmetic.

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

I did a quick scan of my system and both practices are used equally
widely, so unless you intend to address all the authors of all the other
packages as well I suggest you give it up.

> We could use the `-I' method, but who knows what other cruft we'll pick
> up on some systems?

Everybody uses the '-I method'. If you have too many -I's all at once I
suggest either not bothering, or modularizing your code.

> Putting in more than 20 `-I's means we cannot guarantee where anything
> will get included from.

If people have duplicatedly named header files in the default search paths
chances are that *anything* that will use them is going to break. There is
no grand-unified work around so people will have to get down to
organizing their system sooner or later.

Just because you guys are constantly trying to subvert autoconf there's no
reason to let it out on us. :-/

Okay, now *why* does XEmacs need PostgreSQL?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: #include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-11T11:17:16Z

Peter Eisentraut <e99re41@DoCS.UU.SE> wrote:

> You cannot assume that "" does anything differently than <>. The difference
> is cosmetic.

        Really, I'd like you to point me to one known C preprocessor that does
not make the difference. Standards are a good thing, but they are not
immutable, and the evolution leans towards this semantic difference between ""
and <>. It's already explicit in C++ for instance. If 99% of the preprocessors
of the planet work a certain way, I don't see anything wrong in following a
de-facto convention, and I'd encourage people to conform to it, in view to a
very probable standardization. That's exactly what happened in this particular
case.

> I did a quick scan of my system and both practices are used equally
> widely, so unless you intend to address all the authors of all the other
> packages as well I suggest you give it up.

        That's indeed the two attitudes one can adopt. Either you do your on
personal little cruft alone in your corner, or you try to talk with people. We
usually try to "address the authors of the packages we interact with". This
policy is IMHO of a better citizenship.

> Everybody uses the '-I method'. If you have too many -I's all at once I
> suggest either not bothering, or modularizing your code.

        Please, don't you think we already have modularized code ? We're not
trying to find a solution to our problem here. We're trying to find the
*cleanest* solution for *everybody*. Why don't you want to understand that ?
Without any modification on your part, we know how to fix the problem in at
least 3 different manners. But that's just not the point.

        Let me rephrase what I originally wanted to underline:

- Joe provides a library libfoo.
- Joe provides a header libfoo.h, located at /usr/include/libfoo/libfoo.h in
  order to use the library.

Now if this program:

| #include <libfoo/libfoo.h>
| main () {}

can't compile, then, I consider that the installation of the library is
broken, and instead of writing yet another trick in my code, I say to myself
"OK I should tell Joe about this.". What's wrong with that ?! Given that Tom
actually seems to agree with this, and given the answer of the Andres Kardos'
answer, I don't understand your attitude here.

> Just because you guys are constantly trying to subvert autoconf there's no
> reason to let it out on us. :-/

        *subvert* autoconf ?! We're using autoconf exactly in the way it is
done for: to make the life of our users better.

> Okay, now *why* does XEmacs need PostgreSQL?

        XEmacs doesn't need postgresql. It nows supports it, which means
people can write Emacs Lisp packages interfacing with postgres databases, and
benefit from the XEmacs editing features and environment.

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

Re: #include oddity in v7.0b3

Peter Eisentraut <e99re41@docs.uu.se> — 2000-04-11T12:33:59Z

On 11 Apr 2000, Didier Verna wrote:

>         That's indeed the two attitudes one can adopt. Either you do your on
> personal little cruft alone in your corner, or you try to talk with people.

I'm not doing that, I'm just saying that your mission is extremely tough.
I don't really care regarding the original issue of "" vs <> but
considering that you can't rely on this other than on a package by package
and version by version basis your solution is going to be a kludge to the
very end. If you really want to go through with it (substituting absolute
paths into #include statements, that is) I suggest you write a configure
test to see if it works and only use it if it does.

>         Please, don't you think we already have modularized code ?

If you have 20 -I's on the compile line, perhaps not, although I'm not to
judge here.

> We're not trying to find a solution to our problem here. We're trying
> to find the *cleanest* solution for *everybody*.

See above what the cleanest solution for everybody might be and why this
one certainly isn't.

>         Let me rephrase what I originally wanted to underline:
> 
> - Joe provides a library libfoo.
> - Joe provides a header libfoo.h, located at /usr/include/libfoo/libfoo.h in
>   order to use the library.
> 
> Now if this program:
> 
> | #include <libfoo/libfoo.h>
> | main () {}
> 
> can't compile, then, I consider that the installation of the library is
> broken, and instead of writing yet another trick in my code, I say to myself
> "OK I should tell Joe about this.".

The only difference is that we provide a header file which is supposed to
be included as #include <libpq-fe.h>. If you do that then it works. If the
location of this header file is not in the search path for include files,
then tell your compiler about it. The names used in #include are
immutable, they are not expected to follow file system semantics. The
bottom line is that what you're trying is not the way things were supposed
to work. All I'm saying is that you might want to consider not doing it.
There is no harm in having 20 -I's on the compile line unless the user has
more than one header file with the same name on his system, in which case
most everything else on it is going to break as well.

> *subvert* autoconf ?! We're using autoconf exactly in the way it is
> done for: to make the life of our users better.

Rewriting almost every single provided macro in order to disable the cache
surely sounds like subversion to me. (But I agree that the cache is evil.)

>         XEmacs doesn't need postgresql. It nows supports it, which means
> people can write Emacs Lisp packages interfacing with postgres databases, and
> benefit from the XEmacs editing features and environment.

Cool.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: #include oddity in v7.0b3

Jan Vroonhof <vroonhof@math.ethz.ch> — 2000-04-11T14:10:21Z

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

> There is no harm in having 20 -I's on the compile line unless the user has
> more than one header file with the same name on his system, in which case
> most everything else on it is going to break as well.

This in fact one of the problems that caused us to switch to the newer
inclusion mechanism. (prompted by the mess that is libXawXXXX)

Jan

P.S. I would be interested in knowing what problem the user had for
which you made change. Maybe it is relevant for use too?

Re: #include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-11T14:19:25Z

Peter Eisentraut <e99re41@DoCS.UU.SE> wrote:

> >         Please, don't you think we already have modularized code ?
> 
> If you have 20 -I's on the compile line, perhaps not, although I'm not to
> judge here.

        Please read my messages carefully. We *don't* have 20 -I one the
command line, and we don't want to. That's the whole point. Obviously, we can
rewrite particular targets in Makefile.in in order to add the proper -I flags
only to the concerned sources. We have to do this already at some places.
However, this is even dirtier and we want to avoid this as much as possible.

> See above what the cleanest solution for everybody might be and why this
> one certainly isn't.

        This one doesn't prevent you from using the other one, if you
consider it cleaner which is arguable. On the contrary, the current state
breaks our solution, without bringing any benefit to anybody (see
Andreas'message).

> The bottom line is that what you're trying is not the way things were
> supposed to work. 

        "supposed to work" sounds really subjective in this context. Anyway,
that shouldn't prevent us from improving the software by making it work other
ways too (let me remind you that it worked before 7.0).

> There is no harm in having 20 -I's on the compile line unless the user has
> more than one header file with the same name on his system, in which case
> most everything else on it is going to break as well.

        You can't image how much you're right !! Postgres happens to install a
header file named `config.h' in its installation directory. As a consequence,
if we follow your reasoning and if, as you suggest, we don't rely on the
semantic difference of "" and <>, no application using autoconf will be able
to compile a postgres support !! There's really nothing to be proud of :-(

> Rewriting almost every single provided macro in order to disable the cache
> surely sounds like subversion to me.

        It is not. It is trying to improve autoconf when we find deficiencies
(just like I'm trying to do with you here): the autoconf developers are aware
of this and as a matter of fact, the next version of autoconf will have the
cache disable by default. Our script will little by little get simpler, as
both communities will benefit from the work. That's the way I like free
software development the more.

> >         XEmacs doesn't need postgresql. It nows supports it, which means
> > people can write Emacs Lisp packages interfacing with postgres databases,
> > and benefit from the XEmacs editing features and environment.
> 
> Cool.

        Yes :-). Thank Steven Baur for that.

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

Re: #include oddity in v7.0b3

Tom Lane <tgl@sss.pgh.pa.us> — 2000-04-11T15:43:28Z

"Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> I am that other guy. We have fixed our dependency maker in the meantime.

Well, given that Andreas no longer cares, I'm happy to change it back to
the way it was.  "" is definitely more consistent with what we have done
in other include files.

			regards, tom lane

Re: #include oddity in v7.0b3

Didier Verna <didier@xemacs.org> — 2000-04-11T15:46:37Z

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> > I am that other guy. We have fixed our dependency maker in the meantime.
> 
> Well, given that Andreas no longer cares, I'm happy to change it back to
> the way it was.  "" is definitely more consistent with what we have done
> in other include files.

        Great, thanks Tom !

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