Re: proposal - command-line option checking

[Ralf Wildenhues]

* Ed Hartnett wrote on Thu, Dec 14, 2006 at 02:24:37PM CET:
> 
> How about a macro which, when invoked in the configure.ac, would turn
> on such warnings for that configure script.
[...]
> However, this does make life harder on those who are trying to
> assemble collections of releases,

There are several aspects to this issue:

- The typo-apt (or the unwary) user that wishes to be warned for each
  package he builds.  Thus, requiring a macro or a command-line argument
  to enable the warning does not help: it should warn by default.  Not
  only if the developer or the user thought of it.

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

- 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?

- Erroring by default is a no-go: it contradicts GCS.

- (Normal output and) warnings are abundant (why does nobody use
  --silent?).  So have a way to produce a hard error, but it should
  not be the default.  Who should be able to turn on the error?
    user -> command line argument -> ok.
    developer?  I don't think so, too dangerous.

- Probably nice would be if a package tree hierarchy warned only from
  the toplevel package, and excluded all arguments detected by lower
  level configure scripts: AC_CONFIG_SUBDIRS should pass
  --disable-option-checking always then.

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

- How could used arguments be transported by sub-configure scripts?
  * formatted bits of sub/config.log, to be parsed by the upper
    configure script (with some sed scripting).
  * ...?

- 'config.status --recheck' should not warn again, by some means
  (either passing --disable-option-checking, or changing semantics of
  --no-create --no-recursion to also mean --disable-option-checking).

- I'm pretty sure this will still violate some developers' configure.ac
  scripts wrt. backward compatibility.  Can't have it all, I guess.


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
  --disable-option-checking  Do not warn about unknown flags

and a
  AC_DISABLE_OPTION_CHECKING

and that warning output as well as the set of used options should both
be written from the exit trap of the configure script: the former to
stderr, the latter to config.log.

Comments welcome.  I would oppose adding a premature warning now that
would prevent dealing properly with package hierarchies later.  They
are used by some important packages like GCC.

Cheers,
Ralf

PS: to facilitate uniformity in new packages, it would be nice to set
up a list of common flags from different packages that all have the same
(or at least very similar) semantics, like the 'Option Table' in GCS.