Re: proposal - command-line option checking

[Matthew Woehlke]

Ralf Wildenhues wrote:
> [snip]
> There are several aspects to this issue:
> [more snip]
> - The distro maker may want to do
>      for pkg in *; do
>        cd pkg
>        ./configure $common_options && make ...
>        cd ..
>      done
>
>   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.

> - As long as we don't have a way to find out the set of allowed
>   arguments in a package tree hierarchy, there needs to be a way to
>   turn off the warning for a developer.  A new macro would do.
>   Should the macro be overridable by the user?

Shouldn't the upper-level configure know about options in the lower 
level? This would solve this problem, and would be beneficial for option 
discovery as well.

> - When should the warning(s) be output?
>   (Note that M4 allows us some flexibility here, Harlan: we can know at
>   any point in the script the set of detected arguments in that script,
>   even if not dealt with in all control flows.)
>   * Easiest would be during argument parsing loop.
>   * Most obvious would be at (or even after) config.status execution
>     (but developers compete for this nice spot).
>   * Large packages shouldn't configure for 10 min before showing the
>     warning.
>   * Regarding finding out allowed flags in a package hierarchy:
>     We can only know the set of configure scripts by actually running
>     them all: the set may be known only at runtime.  So we can do a good
>     warning only after all have run.
>   * OTOH, if configure errors out early due to wrong or missing
>     arguments, then our warning at the normal end is worthless.

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/.

> My conclusion is that warnings should be on and non-fatal by default,
> there should be a
>   --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, ...?

That's just my $0.02; take it or leave it. :-)

--
Matthew
What? This signature /again/?