Re: [PATCH] Fix treatment of --enable-assert in AC_HEADER_ASSERT

[Paolo Bonzini]

> I've applied your suggestions, and also added a warning
> for the pathological case where a user does something like
> "--enable-assert=kj".  It seems unnecessary, but probably
> doesn't hurt.  How does one typically deal with that
> sort of (ab)usage?  And why does "--disable-assert=kj" cause
> configure to throw an "invalid feature name" warning,
> but "--enable-assert=kj" works okay.  Is that a bug or
> expected behavior?

The error message is a bug, but the error is right because
--disable-assert is just a synonym for --enable-assert=no (and as such
cannot accept parameters).

I'll apply your patch later, just note that...

>    AC_ARG_ENABLE([assert],
> +    AS_HELP_STRING([--disable-assert],[turn off assertions]),
> +    AS_IF([test "x$enableval" = xno],
> +      AC_DEFINE([NDEBUG], [1], [Define to 1 if assertions should be 
> disabled.]),
> +      [test "x$enableval" != xyes],
> +      AC_MSG_WARN([invalid argument supplied to --enable-assert.])
> +      [enable_assert=no]
> +    )dnl
> +  )
> +  AC_MSG_RESULT([$enable_assert])

... all arguments of AC_ARG_ENABLE have to be quoted (the number of
cases in which you do not quote arguments that invoke macros, can be
counted on a single hand probably).

Paolo