Re: mingw configure failure workaround - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: mingw configure failure workaround
Date
Msg-id 40965DB0.8020201@dunslane.net
Whole thread Raw
In response to Re: mingw configure failure workaround  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: mingw configure failure workaround
Re: mingw configure failure workaround
List pgsql-hackers
Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>  
>
>>Even if we don't do that can we *please* put in something that
>>detects the error, and tells the user what they will have to do to
>>fix it? Failing in a situation which we know we can detect and not
>>telling the user is intolerable, IMNSHO.
>>    
>>
>
>Can you try a more recent version of autoconf and see if that behaves 
>more tolerably?
>
>  
>

tested with autoconf 2.59.

Unfortunately, it does not. It does try to copy if a link fails, unlike 
what we have now:
 ln -s $ac_rel_source $ac_dest 2>/dev/null ||   ln $srcdir/$ac_source $ac_dest 2>/dev/null ||   cp -p
$srcdir/$ac_source$ac_dest ||
 

We don't have the last line, which must have been added since autoconf 2.53.

However, the problem is that the first line will actually appear to have 
succeeded, i.e. MSys's ln is lying to us ;-(

This comes from the autoconf macro _AC_OUTPUT_LINKS defined in its 
status.m4, which I guess is what we'd need to override (is that 
possible?) if we are going to detect the failure, or maybe there's some 
more magical way that in my unfamiliarity with autoconf I am unaware of.

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: heapgettup: failed ReadBuffer
Next
From: Tom Lane
Date:
Subject: Re: Fixed directory locations in installs