Re: ./configure argument checking - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: ./configure argument checking
Date
Msg-id 20061013170714.GB28647@nasby.net
Whole thread Raw
In response to Re: ./configure argument checking  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ./configure argument checking  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 13, 2006 at 12:45:23PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > In the meantime, +1 to adding some whitespace around the warning... I'd
> > suggest two blank lines before and after.
> 
> I don't really see that that would accomplish anything.  The problem is
> exactly that configure emits many many lines of output which no one
> bothers to read --- it's been years since it even fit in my terminal
> window's scroll-back buffer :-(  A couple blank lines in there won't do
> much except make the output even longer.

Well, if the warning was close enough to the end it would help. I
thought I'd just missed it, but I just tested again and couldn't find a
warning anywhere (I even grepped config.log). So I suspect that this
functionality is now borked.

> > ... personally I'd much rather have the default
> > be to error-out if it gets garbage arguments. If we provided a flag that
> > disabled that, all porters would have to do is to add that to the myriad
> > of flags they're already passing in.
> 
> This is bending the upstream autoconf developers' idea of what to do
> well past the breaking point ;-).  Still, if we think that bad configure
> arguments is a serious problem, maybe this is what we should do.
> 
> The reason I like the "quiet mode" idea better is that "garbage
> argument" is not the only warning I fear people are missing.  There's
> also the one about "you've got an obsolete Bison", which is either
> extremely important or utterly useless depending on whether there are
> up-to-date prebuilt .c files or not.  That means we can *not* turn it
> into an error condition ... but because it is not close to either the
> beginning or the end of the configure run, it's virtually guaranteed
> that people won't notice it.  If we fixed things so that the warnings
> were pretty nearly the only output, then they'd get noticed.

Hrm... I don't suppose there's a way to capture the critical warnings in
a temporary file and then cat that at the end? (I'm assuming that it'll
be nearly impossible to get a quite mode out of autoconf...)
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] array_accum aggregate
Next
From: "Bucky Jordan"
Date:
Subject: Re: [PERFORM] Hints proposal