On 07/31/2017 01:02 PM, Tom Lane wrote:
> Record full paths of programs sought by "configure".
>
> Previously we had a mix of uses of AC_CHECK_PROG[S] and AC_PATH_PROG[S].
> The only difference between those macros is that the latter emits the
> full path to the program it finds, eg "/usr/bin/prove", whereas the
> former emits just "prove".  Let's standardize on always emitting the
> full path; this is better for documentation of the build, and it might
> prevent some types of failures if later build steps are done with
> a different PATH setting.
>
> I did not touch the AC_CHECK_PROG[S] calls in ax_pthread.m4 and
> ax_prog_perl_modules.m4.  There seems no need to make those diverge from
> upstream, since we do not record the programs sought by the former, while
> the latter's call to AC_CHECK_PROG(PERL,...) will never be reached.
>
> Discussion: https://postgr.es/m/25937.1501433...@sss.pgh.pa.us


The problem with this commit, as jacana is demonstrating, is that on Msys it 
finds the wrong prove. configure needs to run against the perl we build 
against, i.e. a native Windows perl, but prove needs to run with the perl from 
the MSys DTK that understands MSys virtualized paths. I have a hack that will 
allow the buildfarm to overcome the difficulty, (essentially it passes 
'PROVE=prove' to make) but that's fairly ugly and certainly non-intuitive for 
someone running an MSys build and TAP tests without the buildfarm client.

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

Reply via email to