Spent some of my morning fixing a build issue that came down to the use of AC_ARG_ENABLE. I thought it was worth recording some notes for its use:
Something enabled by default:
AC_ARG_ENABLE([badgers],
[AC_HELP_STRING([--enable-badgers=@<:@yes/no@:>@],
[Enable badgers @<:@default=yes@:>@])],
[],
[enable_badgers=yes])
Something disabled by default:
AC_ARG_ENABLE([badgers],
[AC_HELP_STRING([--enable-badgers=@<:@yes/no@:>@],
[Enable badgers @<:@default=no@:>@])],
[],
[enable_badgers=no])
Observe that in this case the only thing that changes is the default value in the third parameter to AC_ARG_ENABLE (and also the documentation 
)
Something enabled by default but with a –disable syntax:
AC_ARG_ENABLE([badgers],
[AC_HELP_STRING([--disable-badgers],
[Disable badgers],
[],
[enable_badgers=yes])
Notice that this case is just the same as the first except with the help changed. Of course you actually need to use the value from the flag. I think this is more readable if presented outside the AC_ARG_ENABLE parameters this is possible because AC_ARG_ENABLE always sets a variable called enable_<thing>. Awesome, huh?
For conditional pkg-config:
AS_IF([test "x$enable_badgers" = "xyes"],
[PKG_CHECK_MODULES(BADGERS, [badgers-1.0])],
[])
For conditional building:
AM_CONDITIONAL(ENABLE_BADGERS, test "x$badgers" = xyes)
Daniel asked me what the @<: @ and @:>@ does … it produces [ and ] in the output.
You really don’t need the [yes/no/whatever] things in the help. The yes and no are implicit when doing –enable and –disable, but sadly a lot of projects don’t handle it correctly and require passing –enable=no to work, which is just silly.
AC_HELP_STRING has been obsoleted by AS_HELP_STRING, it would be nice to get the article updated.
The quoting in your “Something enabled by default but with a –disable syntax” example seems incorrect. Combining the fix with Guillem’s suggestion to use AS_HELP_STRING looks like
AC_ARG_ENABLE([badgers],
[AS_HELP_STRING([--disable-badgers],
[Disable badgers])],
[], [enable_badgers=yes])