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