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

I wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".

BTW, what actually says that is installation.sgml:

<application>Perl</> 5.8 or later is needed to build from a Git checkout,
or if you changed the input files for any of the build steps that
use Perl scripts. If building on Windows you will need
<application>Perl</> in any case. <application>Perl</application> is
also required to run some test suites.

Strictly speaking, there is no statement anywhere (AFAICT) about what
Perl versions PL/Perl works with.

As an experiment, I built from a "make maintainer-clean" state using
that 5.8.0 install, and it worked. So indeed installation.sgml's
statement is correct as far as it goes. But I dunno what the situation
is for the MSVC build scripts. I did not try the TAP tests either.

A look in the buildfarm logs says that the oldest Perl version we're
actually testing is 5.8.6 on prairiedog. (castoroides/protosciurus
have 5.8.4 but they are not building --with-perl, so that only
exercises the build scripts not plperl; they're not doing TAP either.)
I only looked into configure.log results though, so I'm not sure
about the Windows critters.

I kinda suspect we're not actively testing non-MULTIPLICITY builds
either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
so the case doesn't seem actively broken, but I doubt there is any
buildfarm coverage. I wonder if it'd be worth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 07/27/2017 11:58 PM, Tom Lane wrote:

I kinda suspect we're not actively testing non-MULTIPLICITY builds
either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
so the case doesn't seem actively broken, but I doubt there is any
buildfarm coverage. I wonder if it'd be worth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.

It's quite possible, but in general it will need a new buildfarm client release. If you choose a few possibly critical animals we can ask the owners to apply a fairly simple patch.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 07/28/2017 08:22 AM, Andrew Dunstan wrote:

On 07/27/2017 11:58 PM, Tom Lane wrote:

I kinda suspect we're not actively testing non-MULTIPLICITY builds
either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
so the case doesn't seem actively broken, but I doubt there is any
buildfarm coverage. I wonder if it'd be worth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.

It's quite possible, but in general it will need a new buildfarm client release. If you choose a few possibly critical animals we can ask the owners to apply a fairly simple patch.

Looks like this, bit it's rather tedious. I think I might back it out. I
guess I could also write it to a log file, if we really think we need it.

<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&amp;dt=2017-07-28%2018%3A37%3A19&gt;

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 07/27/2017 11:58 PM, Tom Lane wrote:

I wonder if it'd be worth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.

Looks like this, bit it's rather tedious. I think I might back it out. I
guess I could also write it to a log file, if we really think we need it.
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&amp;dt=2017-07-28%2018%3A37%3A19&gt;

Yeah, that's awfully verbose :-(. I suspect most vendors wouldn't bother
with enumerating quite so many patches.

I fixed configure so that it will report what it saw in $Config{ccflags};
that may be sufficient.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".
And the lack of field complaints suggests strongly that nobody else
cares. So I'm inclined to think we just need to be more specific
about the minimum Perl version --- but what exactly?

I've done some more research on this. It seems to me there are four
distinct components to any claim about whether we work with a particular
Perl version:

1. Can it run the build-related Perl scripts needed to build PG from
a bare git checkout, on non-Windows platforms?
2. Can it run our MSVC build scripts?
3. Does pl/perl compile (and pass its regression tests) against it?
4. Can it run our TAP tests?

I have no info to offer about point #2, but I did some tests with
ancient 5.8.x Perl versions on my buildfarm hosts prairiedog and
gaur. (I would have liked to use something faster, but these Perl
versions failed to build at all on more recent platforms, and
I thought it rather pointless to try to hack them enough to build.)

I find that perl 5.8.0 and later seem to succeed at point #1,
but you need at least 5.8.1 to compile plperl. Also, on prairiedog
5.8.1 fails plperl's regression tests because of some seemingly
utf8-related bug. That may be an ancient-macOS problem more than
anything else, so I didn't poke at it too hard.

The really surprising thing I found out is that you can't run the
TAP tests on anything older than 5.8.3, because that's when they
added "prove". I'm bemused by the idea that such a fundamental
facility would get added in a third-digit minor release, but there
you have it. (Now, in fairness, this amounted to importing a feature
that already existed on CPAN, but still...)

5.8.3 does appear to succeed at points 1,3,4. Now, to get through
the TAP tests you need to install IPC::Run, and you also need to
update Test::More because the version shipped with 5.8.3 is too old.
But at least the failures that you get from lacking these are pretty
clear.

I am unable to confirm our claim that we work with Test::More 0.82,
because CPAN has only versions from a year or three back. (Anyone
know of a more, er, comprehensive archive than CPAN?) It's also
interesting to speculate about how old a version of IPC::Run is new
enough, but I see no easy way to get much data on that either.

Anyway, pending some news about compatibility of the MSVC scripts,
I think we ought to adjust our docs to state that 5.8.3 is the
minimum supported Perl version.

Also, I got seriously confused at one point during these tests because,
while our configure script carefully sets PERL to an absolute path name,
it's content to set PROVE to "prove", paying no attention to whether
that version of "prove" matches "perl". Is it really okay to run the
TAP tests with a different perl version than we selected for other
purposes? I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Moin Tom,

On Sun, July 30, 2017 1:21 am, Tom Lane wrote:

I wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".
And the lack of field complaints suggests strongly that nobody else
cares. So I'm inclined to think we just need to be more specific
about the minimum Perl version --- but what exactly?

My 0.02 cent on Perl versions:

Not sure how often People use old Perl versions out in the field. I'd
venture this is either happens with "ancient" stuff, e.g. where people
just can't or want upgrade.

Otherwise, an up-to-date OS is just necessary for security, anyway, and
that would contain a Perl from this decade, wouldn't it?

If someone is still running Perl 5.8.3, they also got glorius Unicode
circa Unicode 4.0 or in this area...

I've done some more research on this. It seems to me there are four
distinct components to any claim about whether we work with a particular
Perl version:

1. Can it run the build-related Perl scripts needed to build PG from
a bare git checkout, on non-Windows platforms?
2. Can it run our MSVC build scripts?
3. Does pl/perl compile (and pass its regression tests) against it?
4. Can it run our TAP tests?

I have no info to offer about point #2, but I did some tests with
ancient 5.8.x Perl versions on my buildfarm hosts prairiedog and
gaur. (I would have liked to use something faster, but these Perl
versions failed to build at all on more recent platforms, and
I thought it rather pointless to try to hack them enough to build.)

I find that perl 5.8.0 and later seem to succeed at point #1,
but you need at least 5.8.1 to compile plperl. Also, on prairiedog
5.8.1 fails plperl's regression tests because of some seemingly
utf8-related bug. That may be an ancient-macOS problem more than
anything else, so I didn't poke at it too hard.

The really surprising thing I found out is that you can't run the
TAP tests on anything older than 5.8.3, because that's when they
added "prove". I'm bemused by the idea that such a fundamental
facility would get added in a third-digit minor release, but there
you have it. (Now, in fairness, this amounted to importing a feature
that already existed on CPAN, but still...)

5.8.3 does appear to succeed at points 1,3,4. Now, to get through
the TAP tests you need to install IPC::Run, and you also need to
update Test::More because the version shipped with 5.8.3 is too old.
But at least the failures that you get from lacking these are pretty
clear.

I am unable to confirm our claim that we work with Test::More 0.82,
because CPAN has only versions from a year or three back. (Anyone
know of a more, er, comprehensive archive than CPAN?) It's also
interesting to speculate about how old a version of IPC::Run is new
enough, but I see no easy way to get much data on that either.

Anyway, pending some news about compatibility of the MSVC scripts,
I think we ought to adjust our docs to state that 5.8.3 is the
minimum supported Perl version.

Also, I got seriously confused at one point during these tests because,
while our configure script carefully sets PERL to an absolute path name,
it's content to set PROVE to "prove", paying no attention to whether
that version of "prove" matches "perl". Is it really okay to run the
TAP tests with a different perl version than we selected for other
purposes? I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

Thank you for the analysis. I agree about "prove".

As for Test::More:

Test::More has been bundled with Perl since 5.6.2 (you can use "corelist"
to check for these things), so if all fails, it might be possible to
extract a version from a Perl distribution [4]http://www.cpan.org/src/5.0/ - tho the timestamps seem to ben have reset on some of the files. 5.8.3 is from 2004 not 2011..

CPAN authors are encouraged to clean out old versions due to the sheer
size of the archive. (Not all got the memo, tho...*cough*) and most
mirrors only carry the current files.

The original author is Michael G. Schwern [0]http://ftp.nluug.nl/languages/perl/CPAN/authors/id/M/MS/MSCHWERN/. But it seems he cleaned
house :)

You might have luck with an mirror [1]http://mirrors.cpan.org/ who didn't clean out, or with
archive.org.

But with Test::More, it seems a bit confusing, as it is part of
Test::Simple [2]http://search.cpan.org/~exodist/Test-Simple-1.302086/, which in turn is part of Test2, which is now on github
[3]: https://github.com/Test-More/test-more

I'm not sure you'd find old Test::More versions ready-to-use in this.

My apologies if you knew that already.

However, I do so happen to have a large archive with Perl releases and
CPAN modules. It was first mirrored on mid-2015 - so anything that was
deleted before 2015 unfortunately I can't help you with that.

But if you need a specific module version, just ping me and I can see if
it's in there.

Hope this helps,

Tels

[0]: http://ftp.nluug.nl/languages/perl/CPAN/authors/id/M/MS/MSCHWERN/
[1]: http://mirrors.cpan.org/
[2]: http://search.cpan.org/~exodist/Test-Simple-1.302086/
[3]: https://github.com/Test-More/test-more
[4]: http://www.cpan.org/src/5.0/ - tho the timestamps seem to ben have reset on some of the files. 5.8.3 is from 2004 not 2011.
reset on some of the files. 5.8.3 is from 2004 not 2011.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:

I wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".
And the lack of field complaints suggests strongly that nobody else
cares. So I'm inclined to think we just need to be more specific
about the minimum Perl version --- but what exactly?

I've done some more research on this. It seems to me there are four
distinct components to any claim about whether we work with a particular
Perl version:

1. Can it run the build-related Perl scripts needed to build PG from
a bare git checkout, on non-Windows platforms?
2. Can it run our MSVC build scripts?
3. Does pl/perl compile (and pass its regression tests) against it?
4. Can it run our TAP tests?

5.8.3 does appear to succeed at points 1,3,4. Now, to get through
the TAP tests you need to install IPC::Run, and you also need to
update Test::More because the version shipped with 5.8.3 is too old.
But at least the failures that you get from lacking these are pretty
clear.

Anyway, pending some news about compatibility of the MSVC scripts,
I think we ought to adjust our docs to state that 5.8.3 is the
minimum supported Perl version.

Works for me. I wouldn't wait for testing of the MSVC scripts. Strawberry
Perl started with 5.8.8. ActivePerl is far older, but it distributes old
versions to subscription holders only. Besides, the main advantage of
old-version support is letting folks use a packaged/preinstalled binary, and
that doesn't apply on Windows.

Also, I got seriously confused at one point during these tests because,
while our configure script carefully sets PERL to an absolute path name,
it's content to set PROVE to "prove", paying no attention to whether
that version of "prove" matches "perl". Is it really okay to run the
TAP tests with a different perl version than we selected for other
purposes?

Typically yes, though one can construct exceptions.

I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

Nah; on my machines, I use /usr/bin/perl and ~/sw/cpan/bin/prove. The latter
is built against the former, so there's no particular hazard.

nm

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Noah Misch <noah@leadboat.com> writes:

On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:

I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

Nah; on my machines, I use /usr/bin/perl and ~/sw/cpan/bin/prove. The latter
is built against the former, so there's no particular hazard.

Well, OK, but I'd still like to tweak configure so that it records
an absolute path for prove rather than just setting PROVE=prove.
That way you'd at least be able to tell from the configure log
whether you are possibly at risk.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Tels" <nospam-pg-abuse@bloodgate.com> writes:

On Sun, July 30, 2017 1:21 am, Tom Lane wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".

Not sure how often People use old Perl versions out in the field. I'd
venture this is either happens with "ancient" stuff, e.g. where people
just can't or want upgrade.
Otherwise, an up-to-date OS is just necessary for security, anyway, and
that would contain a Perl from this decade, wouldn't it?

Well, that's not really the point, IMO. The reason I'm interested in
this is the same reason I run some buildfarm critters on ancient
platforms: if we do something that breaks backwards compatibility
with old software, we should know it and make a deliberate decision
that it's okay. (And update the relevant compatibility claims in our
docs.) Moving the compatibility goalposts without knowing it isn't
good, especially if it happens in supposedly-stable release branches.

I am unable to confirm our claim that we work with Test::More 0.82,
because CPAN has only versions from a year or three back. (Anyone
know of a more, er, comprehensive archive than CPAN?) It's also
interesting to speculate about how old a version of IPC::Run is new
enough, but I see no easy way to get much data on that either.

Test::More has been bundled with Perl since 5.6.2 (you can use "corelist"
to check for these things), so if all fails, it might be possible to
extract a version from a Perl distribution [4].

Yeah, I looked into that. The closest candidate I can find is that
perl 5.10.1 contains Test::More 0.92. However, it's not real clear
to me exactly which files I'd need to pull out of 5.10.1 and inject into
an older tarball --- the layout seems a lot different from a standalone
package.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:

Noah Misch <noah@leadboat.com> writes:

On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:

I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

Nah; on my machines, I use /usr/bin/perl and ~/sw/cpan/bin/prove. The latter
is built against the former, so there's no particular hazard.

Well, OK, but I'd still like to tweak configure so that it records
an absolute path for prove rather than just setting PROVE=prove.
That way you'd at least be able to tell from the configure log
whether you are possibly at risk.

That's an improvement.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Noah Misch <noah@leadboat.com> writes:

On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:

Well, OK, but I'd still like to tweak configure so that it records
an absolute path for prove rather than just setting PROVE=prove.
That way you'd at least be able to tell from the configure log
whether you are possibly at risk.

That's an improvement.

The reason it does that seems to be that we use AC_CHECK_PROGS
rather than AC_PATH_PROGS for locating "prove". I can see no
particular consistency to the decisions made in configure.in
about which to use:

AC_CHECK_PROGS(GCOV, gcov)
AC_CHECK_PROGS(LCOV, lcov)
AC_CHECK_PROGS(GENHTML, genhtml)
AC_CHECK_PROGS(DTRACE, dtrace)
AC_CHECK_PROGS(XML2_CONFIG, xml2-config)
AC_CHECK_PROGS(DBTOEPUB, dbtoepub)
AC_CHECK_PROGS(XMLLINT, xmllint)
AC_CHECK_PROGS(XSLTPROC, xsltproc)
AC_CHECK_PROGS(OSX, [osx sgml2xml sx])
AC_CHECK_PROGS(FOP, fop)
AC_CHECK_PROGS(PROVE, prove)

versus

AC_PATH_PROG(TAR, tar)
PGAC_PATH_BISON
PGAC_PATH_FLEX
PGAC_PATH_PERL
PGAC_PATH_PYTHON
AC_PATH_PROG(ZIC, zic)
PGAC_PATH_TCLCONFIGSH([$with_tclconfig])

I'm tempted to propose that we switch *all* of these uses of
AC_CHECK_PROGS to AC_PATH_PROGS.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Moin,

On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:

"Tels" <nospam-pg-abuse@bloodgate.com> writes:

On Sun, July 30, 2017 1:21 am, Tom Lane wrote:

So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".

Not sure how often People use old Perl versions out in the field. I'd
venture this is either happens with "ancient" stuff, e.g. where people
just can't or want upgrade.
Otherwise, an up-to-date OS is just necessary for security, anyway, and
that would contain a Perl from this decade, wouldn't it?

Well, that's not really the point, IMO. The reason I'm interested in
this is the same reason I run some buildfarm critters on ancient
platforms: if we do something that breaks backwards compatibility
with old software, we should know it and make a deliberate decision
that it's okay. (And update the relevant compatibility claims in our
docs.) Moving the compatibility goalposts without knowing it isn't
good, especially if it happens in supposedly-stable release branches.

Sure, I was just pointing out that moving the goalpost forward knowingly,
as you put it, can be ok vs. trying to support ancient software at all
costs. Reads to me as we are in agreement here.

I am unable to confirm our claim that we work with Test::More 0.82,
because CPAN has only versions from a year or three back. (Anyone
know of a more, er, comprehensive archive than CPAN?) It's also
interesting to speculate about how old a version of IPC::Run is new
enough, but I see no easy way to get much data on that either.

Test::More has been bundled with Perl since 5.6.2 (you can use
"corelist"
to check for these things), so if all fails, it might be possible to
extract a version from a Perl distribution [4].

Yeah, I looked into that. The closest candidate I can find is that
perl 5.10.1 contains Test::More 0.92. However, it's not real clear
to me exactly which files I'd need to pull out of 5.10.1 and inject into
an older tarball --- the layout seems a lot different from a standalone
package.

Module distributions contain a MANIFEST like this:

http://search.cpan.org/~exodist/Test-Simple/MANIFEST

And while reconstructing a module for an old version can be quite a
hassle,, it looks like Test::More is just plain Perl and only uses
Test::Builder::Module.

So basically the two files:

http://search.cpan.org/src/EXODIST/Test-Simple-1.302086/lib/Test/More.pm
http://search.cpan.org/src/EXODIST/Test-Simple-1.302086/lib/Test/Builder/Module.pm

might do the trick. Unless PG uses also Test::Simple or other modules,
which I haven't check, then you just need to add these, too.

And basically, you put these files into a subdirectory, and use:

use lib "mydir";

to tell Perl to load modules from there first.

Here is a sample archive with a modern Test::More and an old Test::More
from 5.10.1. There are two scripts to see how they are loaded and used.

http://bloodgate.com/tmp/test-more-test.tar.gz

One thing to watch out is that this would use the old Test::More, but any
module it loads (or the script use) comes from the system Perl. So the
test might not be 100% complete accurate, f.i. if a newer IO::Scalar is
used with the old Test::More.

You could also compile and install an old Perl version into a local
subdirectory and test with that. That takes a bit more time, though.

Hope this helps,

Tels

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Tels" <nospam-pg-abuse@bloodgate.com> writes:

On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:

Yeah, I looked into that. The closest candidate I can find is that
perl 5.10.1 contains Test::More 0.92. However, it's not real clear
to me exactly which files I'd need to pull out of 5.10.1 and inject into
an older tarball --- the layout seems a lot different from a standalone
package.

So basically the two files:
http://search.cpan.org/src/EXODIST/Test-Simple-1.302086/lib/Test/More.pm
http://search.cpan.org/src/EXODIST/Test-Simple-1.302086/lib/Test/Builder/Module.pm
might do the trick.

Thanks for the hint. I transplanted these files out of a 5.10.1
tarball into 5.8.3, then built as usual:
lib/Test/Simple.pm
lib/Test/More.pm
lib/Test/Builder.pm
lib/Test/Builder/Module.pm
The result seems to work, although it fails a few of 5.8.3's tests,
probably because I didn't copy over the relevant test scripts.
It's good enough to run PG's tests though.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Noah Misch <noah@leadboat.com> writes:

On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:

Anyway, pending some news about compatibility of the MSVC scripts,
I think we ought to adjust our docs to state that 5.8.3 is the
minimum supported Perl version.

Works for me.

Done. I have also reconfigured buildfarm member prairiedog to use
a non-MULTIPLICITY build of Perl 5.8.3, with the oldest Test::More
and IPC::Run versions I could lay my hands on. Although I'd gotten
through a manual "make check-world" with this configuration in HEAD
before touching the buildfarm configuration, I see that it just fell
over in the back branches. So there's still some more fixing to be
done, or else we'll need to change that claim again. Will investigate
once the buildfarm run finishes.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 7/30/17 12:50, Tom Lane wrote:

Noah Misch <noah@leadboat.com> writes:

On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:

Well, OK, but I'd still like to tweak configure so that it records
an absolute path for prove rather than just setting PROVE=prove.
That way you'd at least be able to tell from the configure log
whether you are possibly at risk.

That's an improvement.

I disagree with that, unless there is an actual risk.

The reason it does that seems to be that we use AC_CHECK_PROGS
rather than AC_PATH_PROGS for locating "prove". I can see no
particular consistency to the decisions made in configure.in
about which to use:

We use the "PATH" variants when we need a fully qualified name. For
example, at some point or another, we needed to substitute a fully
qualified perl binary name into the headers of scripts.

If there is no such requirement, then we should use the non-PATH variants.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 7/30/17 12:50, Tom Lane wrote:

The reason it does that seems to be that we use AC_CHECK_PROGS
rather than AC_PATH_PROGS for locating "prove". I can see no
particular consistency to the decisions made in configure.in
about which to use:

We use the "PATH" variants when we need a fully qualified name. For
example, at some point or another, we needed to substitute a fully
qualified perl binary name into the headers of scripts.

If there is no such requirement, then we should use the non-PATH variants.

Why? That risks failures of various sorts, and you have not stated
any actual benefit of it.

In cases where people do things like sticking non-default Perl builds
into nonstandard places, failing to record the absolute path to the
program configure saw is both a documentation fail and a clear hazard
to build reproducibility. I think that "you can change your PATH and
get a different Perl version without reconfiguring" is an anti-feature,
because it poses a very high risk of not actually working.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 7/31/17 14:55, Tom Lane wrote:

We use the "PATH" variants when we need a fully qualified name. For
example, at some point or another, we needed to substitute a fully
qualified perl binary name into the headers of scripts.

If there is no such requirement, then we should use the non-PATH variants.

Why? That risks failures of various sorts, and you have not stated
any actual benefit of it.

What I wrote is merely a description of the current practice. That
practice was in turn developed out of ancient Autoconf standard
practices. There are arguments to be made for doing it differently.

One major PITA with the AC_PATH_* checks is that you can only override
them with environment variables that are full paths; otherwise the
environment variables are ignored. For example, currently, running

./configure PYTHON=python3

will result in the PYTHON setting being ignored. Currently, this only
affects a small number of variables, but if we expanded that, it would
be a pretty significant usability change.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 7/31/17 15:17, Peter Eisentraut wrote:

On 7/31/17 14:55, Tom Lane wrote:

We use the "PATH" variants when we need a fully qualified name. For
example, at some point or another, we needed to substitute a fully
qualified perl binary name into the headers of scripts.

If there is no such requirement, then we should use the non-PATH variants.

Why? That risks failures of various sorts, and you have not stated
any actual benefit of it.

What I wrote is merely a description of the current practice. That
practice was in turn developed out of ancient Autoconf standard
practices. There are arguments to be made for doing it differently.

One major PITA with the AC_PATH_* checks is that you can only override
them with environment variables that are full paths; otherwise the
environment variables are ignored. For example, currently, running

./configure PYTHON=python3

will result in the PYTHON setting being ignored. Currently, this only
affects a small number of variables, but if we expanded that, it would
be a pretty significant usability change.

Plus certain special macros such as AC_PROG_CC don't have a PATH
variant, so you're always going to have some inconsistencies.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

One major PITA with the AC_PATH_* checks is that you can only override
them with environment variables that are full paths; otherwise the
environment variables are ignored. For example, currently, running

./configure PYTHON=python3

will result in the PYTHON setting being ignored.

Really? That seems pretty broken, independently of how many variables
are affected. But the ones you'd be most likely to do that with are
using AC_PATH_PROG already, I think. Having lesser-used program variables
behave inconsistently doesn't seem like much of a win.

I'd almost be inclined to say that we should override that behavior
of AC_PATH_PROG. It is undocumented AFAICS, and it's not amazingly
well thought out, either.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers