> I was struggling with some AC_ARG_ENABLE stuff in my project today. > Seems like some people have done ./configure --enable-foo when the > AC_ARG_ENABLE code was as follows: (simplified) > > AC_ARG_ENABLE(foo > AC_HELP_STRING([--disable-foo], [Disable the usage of foo]), > [AC_DEFINE(USE_FOO, 1, blahjasdf)], > [AC_DEFINE(USE_FOO_ALT, 1, [Use if foo doesn't suit your platform])]) > > So running ./configure --enable-foo would disable foo. I could add a > test: > > AC_ARG_ENABLE(foo > AC_HELP_STRING([--disable-foo], [Disable the usage of foo]), > [ > if test "$enableval" = no; then > AC_DEFINE(USE_FOO_ALT, 1, Use the alternative to foo) > else > AC_DEFINE(USE_REAL_FOO, 1, [Use if foo is good on your > platform]) > fi > ], > [AC_DEFINE(USE_REAL_FOO, 1, [Use if foo is good on your platform])])
A more canonical approach to using AC_ARG_* is to use a shell var to hold the switch: AC_ARG_ENABLE(foo AC_HELP_STRING([--disable-foo], [Disable the use of foo]), [use_foo=$enableval], [use_foo=yes]) if test $use_foo = yes; then AC_DEFINE(USE_FOO, 1, [Define if your system has a foo.]) else AC_DEFINE(USE_FAKE_FOO, 1, [Define if you want faked foo functionality]) fi This fairly elegant and allows the user to decide what the 'default' value is. It also allows you to clump AC_ARG calls together, then handle them at leisure later in the script. Note that it seems odd to define two different macros - why not use AC_DEFINE only if foo is enabled, or use a two-valued macro (0 or 1)? (As an aside, 'usage' is 'the way something is used' - so you're not disabling foo's usage, but its use.)
