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: mux66ton2j6.fsf@uzeb.lrde.epita.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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 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(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

Browse pgsql-bugs by date

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