On Fri May 04 08:18:13 2007, doughera wrote: > 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.
Agreed. > > 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. > Also agreed. IMO, the primary test of Configure.pl working is that parrot is built and the tests that test /parrot/ features work. I'm rejecting the original request, however, as something that isn't going to change in the current incarnation of Configure.pl. It should definitely be considered as part of the rewrite of the configure system, currently planned for 3.0 (https://trac.parrot.org/parrot/wiki/ParrotLongTermRoadmap). Regards. -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
