Skip site navigation (1) Skip section navigation (2)

Re: #include oddity in v7.0b3

From: Didier Verna <didier(at)xemacs(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Stephen J(dot) Turnbull" <turnbull(at)sk(dot)tsukuba(dot)ac(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, bugs(at)postgresql(dot)org, XEmacs beta testers <xemacs-beta(at)xemacs(dot)org>, Oliver Elphick <Oliver(dot)Elphick(at)lfix(dot)co(dot)uk>
Subject: Re: #include oddity in v7.0b3
Date: 2000-04-11 14:19:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)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 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

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

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2000-04-11 14:28:59
Subject: Re:
Previous:From: Jan VroonhofDate: 2000-04-11 14:10:21
Subject: Re: #include oddity in v7.0b3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group