[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal - command-line option checking

From: Matthew Woehlke
Subject: Re: proposal - command-line option checking
Date: Thu, 14 Dec 2006 13:19:26 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061025 Thunderbird/ Mnenhy/

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

What? This signature /again/?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]