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])