Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Jim Meyering wrote on Mon, Aug 18, 2008 at 03:59:18PM CEST:
>> Ralf Wildenhues <[EMAIL PROTECTED]> 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?
