> 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
