Peter Eisentraut wrote:
Andrew Dunstan wrote:
However, the problem is that the first line will actually appear to
have succeeded, i.e. MSys's ln is lying to us ;-(
Then msys needs to be fixed. There is certainly a bunch of
autoconfiscated software that gets compiled on mingw/msys every da
Andrew Dunstan wrote:
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
> 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 l
Andrew Dunstan wrote:
> However, the problem is that the first line will actually appear to
> have succeeded, i.e. MSys's ln is lying to us ;-(
Then msys needs to be fixed. There is certainly a bunch of
autoconfiscated software that gets compiled on mingw/msys every day. I
would like to know w
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
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 vers
Andrew Dunstan wrote:
> >It's different because we know why we need that one: we understand the
> >cause of the behavior and we therefore can have some confidence that the
> >kluge will fix it (or not, as the case may be). I have zero confidence
> >in looping five times around an "ln" call.
> >
>
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The real issue in my mind is why is "ln" unreliable in mingw? I cannot
see any point in a retry kluge when we do not know what's really going
on.
I'm still trying to find out. But I don't see why this is
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The real issue in my mind is why is "ln" unreliable in mingw? I cannot
>> see any point in a retry kluge when we do not know what's really going
>> on.
> I'm still trying to find out. But I don't see why this is different from
> the
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
And if not 3), is there some autoconf wizard out there who can help do
this properly? It would probably take me many hours to work out, as I
have never touched the beast.
Obviously, or you would know that configure is a generated
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> And if not 3), is there some autoconf wizard out there who can help do
> this properly? It would probably take me many hours to work out, as I
> have never touched the beast.
Obviously, or you would know that configure is a generated file that
there i
11 matches
Mail list logo
