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