Something that has been bothering me for a long time has been Autoconf's
lack of checking for command-line options. That is, it doesn't give any
error, or even a warning, if the user accidentally types --with-foo or
--enable-ffoo instead of --enable-foo. In my experience, this has
caused numerous problems because users think they've enabled things when
they haven't. (Heck, it's burned me several times on my own programs!)
Not only is it unfriendly, it's also unexpected: virtually every other
Unix command-line program complains if you pass it an unknown argument.
Yes, I know that programs which use AC_CONFIG_SUBDIRS need to pass
options through without checking since they might be used in
subdirectories. But these are the exception, not the rule, and it
doesn't make sense to penalize most users for this.
Hence, PROPOSAL:
* Autoconf configure scripts should check their --with and --enable
arguments, and exit with an error if the option was not specified in an
AC_ARG_ENABLE or AC_ARG_WITH statement, unless:
* This option-checking is disabled if AC_CONFIG_SUBDIRS is used.
(At least initially; a future implementation may check the available
options in the subdirectories, if a good way can be found to do this.)
* The option checking can be disabled by using a new macro,
AC_DISABLE_OPTION_CHECKING, or by passing --disable-option-checking, for
those people who prefer or require the legacy behavior for some reason.
What do people think? I don't want to code up a patch until there is
some consensus about the desired functionality.
Steven G. Johnson
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
