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

Re: make caught doing what configure should...

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: make caught doing what configure should...
Date: 2001-03-23 16:52:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010323 08:47] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> >> Besides, I think the warning message is appropriate in any case, since
> >> it lets bison-less people know that they had better not blow away gram.c
> >> or hack on gram.y.
> > Er, not really, it (the warning) gets blown away by all the rest
> > of the ./configure output.  It might as well error out, not just
> > warn, then you can actually see the message.
> Erroring out would be completely inappropriate unless we had made an
> *accurate* check that gram.c was out of date.  I think that's probably
> a cure worse than the disease; we risk unnecessary configure failures
> to gain, well, not a lot.  You're right that configure's output is too
> chatty for many people; but isn't there a "--quiet" option?  Seems like
> that's what they should be using if they don't want to see details.

GRR! :)

The make will still bomb out. 

It's my opinion that if the configure script detects a situation
that will make compilation impossible _it_ should abort, not proceed
to allow the user to run make when it knows it will not succeed.

I mean it wouldn't make much sense for it to give a warning about
all variants of "fork()" not existing would it?

-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
Daemon News Magazine in your snail-mail!

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2001-03-23 17:02:39
Subject: Re: make caught doing what configure should...
Previous:From: Tom LaneDate: 2001-03-23 16:47:13
Subject: Re: make caught doing what configure should...

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