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

[Gary V. Vaughan]

Hallo Ralf,

On 27 Jun 2010, at 17:23, Ralf Wildenhues wrote:
> * 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 ...

Here, you appear to be saying that the last line of code above is harmless,
but probably unnecessary...

>> 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?

But now you say the line is garbage.

>  Is that what you're implying?

Of course not.  I'm saying that the swathe of deep shell incantations
we need to use to support peculiar shells are beyond my ability to hold
all in my head at once.  To mitigate that problem, I copy the surrounding
code - particularly when I'm refactoring existing code.

If the idiom is garbage after all, then we need a different patch to
tackle fixing it everywhere at once, rather than ignoring the existing
garbage when adding new code.

>>>> +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?

If there was anything other than a vanishingly small probability that
someone would accidentally set _lt_xsi_replace_fail=: in the environment,
I would agree.

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

As I said, I'm not strongly opposed to changing it, but it is certainly
a little more convenient for me to test (rather than editing the
generated file), and for the end user to get a working libtool script
rather than a hard failure.

> 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.

If your disk is full, everything else will start failing at any second,
and a failed xsi shell script substitution in your current build is the
least of your problems.  More likely the hard error would be caused by
a permissions problem... with just a warning the user may choose to
investigate and fix it, or shrug and accept that they'll save more
time running a fractionally slower libtool than being forced to diagnose
what went wrong, and fix it correctly, and rerun their build.

> 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?

I'm really not arguing with you.  While I still have a slight preference
for the way I did it, if you'd rather change it that's perfectly fine
with me too, and will take you less time than explaining why you disagree
with me...

Cheers,
-- 
Gary V. Vaughan (address@hidden)