Re: Patch to install config/missing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to install config/missing
Date
Msg-id 17197.1446498438@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to install config/missing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch to install config/missing  ("David E. Wheeler" <david@justatheory.com>)
Re: Patch to install config/missing  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 30, 2015 at 2:42 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Currently, config/missing isn't being installed. This can lead to confusing
>> error messages, such as if Perl isn't found and something needs it [1].
>> Attached patch adds it to install and uninstall recipes.

> I find it somewhat hard to believe this is the right thing to do.  But
> if this isn't right, then I don't know what is right, either.

Installing our "missing" script seems like a seriously bad idea.  For one
thing, as the comments in it note, it's similar but not identical to such
a script that exists in many GNU packages; we could easily create problems
for other packages that rely on other variants of it.

I wonder how much we need that script at all though.  If, say, configure
doesn't find bison, what's so wrong with just defining BISON=bison and
letting the usual shell "bison: command not found" error leak through?
I'm not seeing that we get a very large increment of user-friendliness
from interposing the "missing" script.  In at least one way it's a net
negative: if you go and install bison after getting the error, you will
have to re-run configure to recover, whereas playing dumb would frequently
have left us with the right configuration output already.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Patch to install config/missing
Next
From: Robert Haas
Date:
Subject: Re: ALTER SYSTEM vs symlink