* 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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
