Re: proposal - command-line option checking

[Matthew Woehlke]

Ralf Wildenhues wrote:
> * Matthew Woehlke wrote on Thu, Dec 14, 2006 at 06:17:47PM CET:
> > Ralf Wildenhues wrote:
> > > - 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.

Um... I'm going to guess I failed to communicate clearly. What I meant 
was 'after I fire off configure' (i.e. by typing, at an interactive 
shell, './configure <...>' and then >>pressing 'enter'<<), chances are 
I'm not going to forget about the screen I was just looking at so fast 
that I don't notice the first few lines it spits out. Not that the 
configure script itself would ever need you to press 'enter'. Does that 
clarify?

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

Right... but the AC_SUBDIRS is a little trickier. How do you know that a 
subdir script will handle the option? This might be a case for Harlan's 
suggestion to have some communication mechanism to pass back up what 
options were accepted so that a list of any that /no/ script ate could 
be output at the end (and then, as you say, suppress them at the beginning).

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

Ah, yes, I see the problem now. But to extend that analogy, 
'--enable-option-checking' would cancel '--disable-option-checking' 
somehow, since otherwise it would be the default. The behavior you are 
talking about deals with two different things. Maybe using something 
like '--option-checking=off|warn|error' with the default 'warn' would be 
better?

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

Aw, nuts. You do have a good point there. In that case, the only obvious 
solution is to have two '--enable's; 'check-options' and 
'check-options-fatal' (as possible examples). Or use the original 
"inconsistent" syntax. Hard to say. I'm just pointing out observations, 
don't feel obligated to listen to them. :-)

--
Matthew
What? This signature /again/?