Horton

Re: PL_stashcache, or, what's our minimum Perl version?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org
Date: 2017-08-01T00:17:16Z
Lists: pgsql-hackers

Attachments

I wrote:
> If we need to fix things so that AC_PATH_PROG will honor a non-path
> input value, then let's do that.  But let's not make the build system
> shakier/less reproducible than it is already.

> I suggest that we could inject logic like this:

>   if VARIABLE-is-set-and-value-isn't-already-absolute; then
>     VARIABLE=`which $VARIABLE 2>/dev/null`
>   fi

> in front of the existing logic for AC_PATH_PROG(VARIABLE,...).
> Maybe "which" isn't the best tool for the job, not sure.

Concretely, how about something like the attached?

BTW, I haven't done it here, but I wonder whether we should not make
PGAC_PATH_PROGS invoke AC_ARG_VAR on the target variable, so that
configure knows that it should be treated as affecting results caching.

			regards, tom lane

Commits

  1. Adjust configure to insist on Perl version >= 5.8.3.

  2. Further improve consistency of configure's program searching.

  3. Doc: specify that the minimum supported version of Perl is 5.8.3.

  4. Record full paths of programs sought by "configure".

  5. Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is