On 08/07/2017 04:07 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> 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:
>
> PROVE=$perlpathdir/prove
>
> Otherwise you're basically lying to configure about what you're going
> to use, and that's always going to break eventually.
Hmm, you're saying this should work now? OK, I'll try it when I get a
minute to spare.
>
>> 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.
WFM
> Are there any other gotchas in the build sequence?
>
Not that I can think of.
> Do we have/need any explicit references to the test version of "perl",
> or is "prove" a sufficient API?
>
>
Probably sufficient.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services