Andy Dougherty wrote:
On Tue, 1 May 2007, James Keenan via RT wrote:
On Tue Apr 10 01:45:31 2007, [EMAIL PROTECTED] wrote:
Configure should act as though writing --foo=no is false instead of
true. Tonight I tried using --execcapable=no to get around a compile
failure, but then realized that it would probably treat "no" as a true
value.
I'm okay with having a plain English representation for "false value",
as long as we have exactly one. Pick 'no', 'none', 'false', or whatever
but we won't try to support every possible value a user might type in to
mean false. Whatever we pick will mean false everywhere, on every
option. And we have to be careful to make sure it's not a value that
someone might want to use as a string value.
One thing that is really needed is a consistent vision for what the
different options expect. Currently, there are at least four different
ways in the help menu to turn stuff off:
--nomanicheck
--cgoto=0
--without-gdbm
--icu-config=none
This means that for undocumented things, like -execcapable, the user has
to guess.
Agreed, this is in serious need of a cleanup.
In short, YAGNI. What do others think?
I'm afraid I don't have any idea what YAGNI means.
"You Ain't Gonna Need It" (a.k.a. the philosophy of avoiding
over-engineering).
Configure.pl will eventually end up setting many, many variables. It is
impossible to predict ahead of time which ones users will want or need
to override. Providing separate --foo options for every single one of
them doesn't scale well at all. Configure.pl's help screen is already
114 lines long.
I'm inclined to keep the plain English --foo names. At first glance it
does seem simpler to only offer one -D option, but all it does is push
the complexity down one level (a long list of options under -D, instead
of a long list of options at the top level). And -D in itself isn't
particularly meaningful, while choosing some naming conventions like
--set-foo, --unset-foo --enable-foo, --disable-foo, etc will go a long
way toward making the configuration system saner to use.
For the implementation, it doesn't particularly matter if you parse
options first as -D and then dispatch on the remaining text, or just
dispatch on the full text option. Agreed that the help screen shouldn't
display every possible option in a long list, but it can break the help
down into sensible groups whether it uses short options like -D, or long
options.
Allison
