Re: pg_regress breaks on msys

Tom Lane wrote:

>I wrote:
>  
>
>>Ah-hah, so apparently "make install DESTDIR=foo" somehow inserts DESTDIR
>>after that instead of before it?  What we need is a way to determine the
>>paths that make install used ...
>>    
>>
>
>AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir
>etc, for instance this is how initdb/Makefile installs initdb:
>
>    $(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)'
>
>The evidence at hand says that this should produce exactly the same path
>string as pg_regress is then using to call initdb.  So the question in
>my mind now is how come the "make install" step isn't failing.  For that
>matter, this same path-construction technique was used by the
>shellscript... so how come it worked before?
>
>It would be simple enough to make pg_regress strip off a drive letter
>from the path strings it receives from the Makefile, but I'm not seeing
>a principled way to discover that the "/msys/1.0/" part has to go.  How
>are the makefiles managing to generate a different value of $(bindir) at
>install time than what was passed into pg_regress at build time?
>
>            regards, tom lane
>
>  
>

I think we'll need to have the makefile tell us what it thinks the cwd 
is, so if it's a virtual path we'll be able to use that.

Compare the install log on the 8.1 branch (from our new buildfarm member 
bandicoot) here  
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=bandicoot&dt=2006-07-19%2009%3A52%3A28&stg=check 

with what seahorse is showing. Note that the install does not involve 
windows paths at all - just Msys virtual paths. But we do need to use 
Windows paths for the data files.

cheers

andrew