On Fri, 4 May 2007, James Keenan via RT wrote:
> On Thu May 03 21:02:21 2007, allison <!-- x --> at perl.org wrote:
> > Andy Dougherty wrote:
> > > On Tue, 1 May 2007, James Keenan via RT wrote:
> > >
> > >> On Tue Apr 10 01:45:31 2007, jrisom <!-- x --> at gmail.com 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.
It may be sensible to distinguish boolean and string variables to avoid
that problem.
> The more you multiply variant ways of providing values to options,
> -- the more code you have to write,
> -- the more code someone has to maintain,
> -- the more tests someone has to write to verify the validity of the code and
> ensure high
> coverage by the tests, and
> -- the more documentation someone has to write to explain the code.
Yes. I think we're all on the same page here. There are currently
multiple ways to say "no":
> --nomanicheck
> --cgoto=0
> --without-gdbm
> --icu-config=none
>
> This means that for undocumented things, like -execcapable, the user has
> to guess.
I'm recommending replacing them with a single way to say "no". Whether
that single way is spelled -Ufoo, --unset-foo, --disable-foo, --no-foo,
or --foo=0 is a Configure human-interface design decision (and then an
implementation detail), but supporting a single way is less work in the
end than the current 4 ways.
> For at least the third of those tasks, that someone, currently, is me.
Believe me -- I am truly very sympathetic to that problem.
> I'm hoping to recruit additional people to help maintain Parrot's Perl 5
> configuration and
> build tools, and I made some progress in this regard at Hackathon Toronto.
> Still, almost all
> of Configure.pl's options are completely untouched by the test suite. Code
> coverage for the
> config/*/*.pm hierarchy is generally only around 25%. Why multiply features
> for which, if
> we're following best practices, we ought to write tests when we don't have
> the people to write
> those tests?
I'm advocating *reducing* the number of options -- replacing the
hand-maintained hodge-podge of current options by a more generic scheme.
Then, within that generic scheme, I expect it will likely be no big
deal to internally treat --set-foo="no" as equivalent to --set-foo=0 or
--unset-foo (at least for boolean variables).
In perl5's Configure, there are over a thousand variables that can
be set by command-line options. Presumably parrot will end up with a
similar number. Attempting to write tests for them all would be madness.
--
Andy Dougherty [EMAIL PROTECTED]
