Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I don't understand. Are you trying to save bytes in configure.in? If
> > we can make problem resolution easier, why wouldn't we do that?
>
> I think he's saying that trying to narrow down the reasons for a failure
> is not configure's job: if we buy into that then we'll soon have a
> monstrous configure script with a huge number of essentially duplicative
> error checks. That costs maintenance effort, not to mention user time
> to run a slower script.
Well, I didn't advocate adding it for every case but in places where
people are experiencing problems, I see no reason not to add a little
help. Heck, we do the same in our commands; we don't just throw out a
failure from pg_dump and tell them to look at some log somewhere. If we
can guess the cause of the error, we tell them.
However, if we could do a better job of throwing out the actual error
Ant and gcc and others generate, that would be a huge win.
> Also, the more such checks we provide in the hope of offering a "more
> specific" error message, the greater the chance of providing a message
> that is more specific and *wrong*, thus misleading the user and causing
> him to waste time instead of save it.
>
> "Look in config.log" is good general-purpose advice for understanding
> configure-detected problems. I don't think we should spend effort
> on special-casing problems that are adequately explained if one looks
> in the log.
Where do we tell them to look in config.log? I have never see it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
