Re: interrupt causes parse error in configure script

[Jim Meyering]

Ralf Wildenhues <address@hidden> wrote:

> * Jim Meyering wrote on Mon, Aug 18, 2008 at 03:59:18PM CEST:
>> Ralf Wildenhues <address@hidden> wrote:
>>
>> > Maybe all you want to prevent is errors from inside the trap code?
>>
>> No, I want to avoid the parse error.
>
> We are talking past each other.  I'm arguing that the parse error is
> typically helpful, not harmful.
>
> Bruno does in several places in gnulib:
>
>   # Long computation that sets gl_cv_XXX
>   ...
>
>   # The following gives an error if gl_cv_XXX has not been set:
>   # Yes, the omission of double quotes is *on purpose*, because
>   # each time 'test' gives an error here, it means the long
>   # computation above has a logic error.
>   if test $gl_cv_XXX ...; then
>     ...
>
> So, each time we encounter an undefined variable, we actually find a
> logic error in a configure macro.  Nice side effect!

Hi Ralf,

Yes, I am familiar with that idiom (I've been writing
autoconf macros that use it for over 12 years).
However, no code like that is affected, since it is not using
"test AS_GET_VAR([some_var]) = yes".

Notice that all changed uses in autoconf are something like
this, where the variable in question is always set:

    AC_CACHE_CHECK([for $1], [ac_Header],
                   [AS_VAR_SET([ac_Header], [$literal_or_set])])
    AS_IF([AS_VAR_YES([ac_Header])], [$2], [$3])[]dnl

> Your patch papers over all those bits.

As far as I can see, that patch does not paper over anything.
Can you give an example?

> So, let's see what you actually encounter.  When you hit ^C, then the
> normal code during some configure test, should not be executed any more
> anyway, only trap code should be executed.  Consequently, "fixing"
> AC_CHECK_FILE, AC_CHECK_DECL, AC_CHECK_FUNC (haven't checked further)
> should be moot anyway: they are never used in the trap code.

If my change has no down-side, isn't all of this moot?