Re: proposal - command-line option checking

[Ralf Wildenhues]

* Matthew Woehlke wrote on Thu, Dec 14, 2006 at 06:17:47PM CET:
> Ralf Wildenhues wrote:
[...]
> >  So even when we have a way to find out the set of allowed arguments
> >  in a package tree hierarchy, we cannot find out the set of allowed
> >  (or useful) arguments in above.  So there needs to be a way to turn
> >  off the warning for the user.
> 
> WFM, but also warnings can be ignored. Chances are if you do something 
> like the above, you know that not all packages will take the same 
> '--with-', '--enable-', etc arguments and can handle seeing the warnings.

Agreed.  I should have written: "needs to be a way to turn off errors".

Bob already answered the next question.

> >- When should the warning(s) be output?

> I would say 'at the beginning', and make 'em good and noisy, so unless 
> the user hits 'enter' and looks away really fast, they'll notice. Then 
> they can ctrl-C the script and fix things without having to wait. 
> Possibly include a briefer notice at the end /in addition/.

Interactive scripts are bad, at least in the general case.

I agree that a warning at the beginning would be helpful.  One could
refine like this: If `--disable-option-checking' has not been passed,
then output

- a warning at the beginning about args not handled by this script
  (only if no AC_CONFIG_SUBDIRS seen?);
- a refined warning at the end (only if AC_CONFIG_SUBDIRS seen?).

Would it be preferable to have the warnings twice for consistency among
packages, or to have them once for reduced output clutter?

> >  --enable-option-checking   Error out for unknown flags
> 
> But we just said it *is* enabled by default? :-) I think this should be 
> something that reflects that you are turning a warning into an error. 
> Something like --option-checking-errors, --option-check-fatal, ...?

I'm bad at naming.  Can we find a good name so that --enable-$feature
and --disable-$feature both make sense?  If not, then two different
$feature's, but what semantics should the respective --enable/--disable
of the other feature have then?  (I was thinking along the lines of
--enable/disable-dependency-tracking, which also have 2 meanings.)

If we use something other than --enable/--disable, then package trees
that are built with different Autoconf versions suffer.

Cheers,
Ralf