On 08/07/2017 04:07 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@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 -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers