Andrew Dunstan <> writes:
> On 08/07/2017 03:36 PM, Tom Lane wrote:
>> My goodness, that's ugly.  Is it really better than injecting
>> "PROVE=prove"?  (I'd suggest saying that to configure, not make,
>> so that the configure log bears some resemblance to what you
>> want done.)

> This is what we had to do BEFORE the change in this commit. Now it's no
> longer sufficient.

Sorry, I was imprecise.  What I'm suggesting is that you drop the
runtime PATH-foolery and instead put this in configure's environment:


Otherwise you're basically lying to configure about what you're going
to use, and that's always going to break eventually.

> It would certainly be better if we could tell configure a path to prove
> and a path to the perl we need to test IPC::Run against.

Hm, yeah, the IPC::Run test would need to deal with this as well.
A PROVE_PERL environment variable is one way.  Or maybe simpler,
just skip the probe for IPC::Run if PROVE has been specified
externally; assume the user knows what he's doing in that case.
Are there any other gotchas in the build sequence?

> The problem in all this is that we're assuming incorrectly that the perl
> we use to build against is the same as the perl we need to run the build

... I think you meant "TAP tests" here ? --------------------------- ^^^^^

> with. On Msys that's emphatically not true.

Do we have/need any explicit references to the test version of "perl",
or is "prove" a sufficient API?

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to