Re: [SCM] GNU Libtool branch, master, updated. v2.2.10-35-gee2dde8

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Sun, Jun 27, 2010 at 11:52:32AM CEST:
> On 27 Jun 2010, at 15:49, Ralf Wildenhues wrote:
> >> --- a/libltdl/m4/libtool.m4
> >> +++ b/libltdl/m4/libtool.m4

> >> +} # XSI $1 implementation' "$cfgfile" > $cfgfile.tmp \
> >> +  && mv -f "$cfgfile.tmp" "$cfgfile" \
> >> +    || (rm -f "$cfgfile" && cp "$cfgfile.tmp" "$cfgfile" && rm -f 
> >> "$cfgfile.tmp")
> > 
> > FWIW, I don't think this line is needed, but it shouldn't hurt either.
> > However, if the cp fails, it might have done half of its work before
> > finding out that the disk is full, so the script might actually be
> > garbage after that, so ...
> 
> Just copying the style of the surrounding code.  Feel free to remove
> the last line if you'd prefer.

So we now consider adding garbage OK only because there exists garbage
elsewhere already?  Is that what you're implying?

> >> +test 0 -eq $? || _lt_xsi_replace_fail=:
> >> +])

> >> +if test x"$_lt_xsi_replace_fail" = x":"; then
> >> +  AC_MSG_WARN([Unable to substitute faster XSI functions in $ofile]) 
> > 
> > ... I think this should indeed be a hard error.  Also, I don't see where
> > _lt_xsi_replace_fail is initialized in the good case; it should be.
> 
> That would prevent me from checking that the warning works with:
> 
>   ../configure _lt_xsi_replace_fail=:
> 
> The absolute worst case scenario for leaving it as I've done it, is
> that somehow the environment gets _lt_xsi_replace_fail set to ":",
> and then the user will see a spurious warning even though the
> substitutions did work in actuality.

So, a false warning is not a sign of bad engineering?

Please search the lists for the numerous complaints Libtool has gotten
because of false warnings.  That way is not The Right Way[tm].

> Why do you want to force a hard failure?  The warning is the very
> last line a user will see after a non-substituting configure run,
> and even if they ignore it, libtool will still work correctly.

Not if that cp fails half-way through.

The warning is almost never the last line I'd see, because for me,
configure gets triggered by 'make' which then happily proceeds to do
nasty things.  No, if the disk is full, I really want a hard error.

> I'm
> not strongly opposed to your changing it if that's what you would
> prefer, but I find the current implementation more convenient for
> developers and users.

We've made Autoconf config.status quite strict by now in presence of
write errors.  I think having reliable code is good.  Would you
disagree?

Thanks,
Ralf