[perl #42412] Configure.pl things =no is true
Joshua Isom
# Please include the string: [perl #42412]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42412 >
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.
James Keenan via RT
> 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 discussed this ticket with other participants in the recent hackathon in Toronto. I am
inclined to recommend that we not make any changes in Configure.pl's behavior as implied
by the ticket, for a number of reasons:
1. Configure.pl is a Perl script. The truth value of the string 'no' in Perl is true. Cet. par., in
Perl if you want to negate something you 'undef' it or you assign it a value of 0 (or the string
'0'). So the current behavior of the 'execcapable' option is consistent with Perl's customary
behavior.
2. In config/auto/jit.pm, $execcapable is set to 1 for Unix-ish operating systems and
Windows and set to 0 for other OSes. But if you want to set a different behavior, it appears
to me that you can simply pass a value of 1 or 0 to the execcapable option.
3. If we really thought we'd make extensive use of something equivalent to '--
execcapable=no', we could create a '--noexeccapable' option analogous to '--
nomanicheck' (see lib/Parrot/Configure/Options.pm).
4. AFAICT from looking at Perl 5's Configure.sh, Perl 5 survives without a 'no' value for any
of its configuration options.
In short, YAGNI. What do others think?
kid51
Andy Dougherty
> On Tue Apr 10 01:45:31 2007, jri...@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 discussed this ticket with other participants in the recent hackathon
> in Toronto. I am inclined to recommend that we not make any changes in
> Configure.pl's behavior as implied by the ticket, for a number of
> reasons:
> 1. Configure.pl is a Perl script. The truth value of the string 'no'
> in Perl is true. Cet. par., in Perl if you want to negate something you
> 'undef' it or you assign it a value of 0 (or the string '0'). So the
> current behavior of the 'execcapable' option is consistent with Perl's
> customary behavior.
The language in which Configure.pl is written is an implementation detail.
Though using 1 and 0 for true and false is a perfectly reasonable interface
model to present to the outside world, it's also sensible to be tolerant
of users.
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.
> 2. In config/auto/jit.pm, $execcapable is set to 1 for Unix-ish
> operating systems and Windows and set to 0 for other OSes. But if you
> want to set a different behavior, it appears to me that you can simply
> pass a value of 1 or 0 to the execcapable option.
Except that the --execcapable option isn't documented as taking a value.
How is the user to know?
> 3. If we really thought we'd make extensive use of something equivalent
> to '-- execcapable=no', we could create a '--noexeccapable' option
> analogous to '-- nomanicheck' (see lib/Parrot/Configure/Options.pm).
> 4. AFAICT from looking at Perl 5's Configure.sh, Perl 5 survives
> without a 'no' value for any of its configuration options.
I don't know exactly what you mean. As a general rule, Configure uses
-D to define something, and -U to undefine it. However, since we often
need more than a simple boolean, the -D and -U syntax is richer and
allows setting nearly arbitrary things. That richer syntax feeds back
into user expectations, and that feedback has led us to accept a variety
of equivalent ways of saying the same thing.
For example, to turn off optimization, either of the following are
equivalent:
Configure -Doptimize=none
Configure -Uoptimize
The second actually sets $optimize=undef, but I assume that the
user probably didn't literally mean to pass the flag 'undef' to the
C compiler in the hopes that the compiler would then optimize the program.
Rather the user's intention was clearly to disable optimization.
Configure thus considers both cases equivalent.
This can get out of hand, of course: For example, if you want
to not use threads, any of the following are equivalent:
Configure -Dusethreads=no
Configure -Dusethreads=false
Configure -Dusethreads=undef
Configure -Uusethreads
The last two are identical in setting $usethreads=undef. The others
work because Configure tests with
case "$usethreads" in
$define|true|[yY]*)
The 'define/undef' interface is generally the "official" way to set
booleans, but supporting the true/false and yes/no variants is a courtesy
to the user that costs nearly nothing to implement.
In short, it seems to me that the user's intent was obvious in writing
--foo=no, and if foo is a boolean, you ought to honor the user's intent,
even if the user didn't use the official 1/0 notation.
> In short, YAGNI. What do others think?
I'm afraid I don't have any idea what YAGNI means.
But I'll continue anyway. Here's what I think:
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.
Instead, what I think is needed is a meta-syntax -- a way of setting
(nearly) arbitrary Configure.pl variables to (nearly) arbitrary values.
Though that syntax can and should declare an 'official' way to set
booleans (and 1/0 is one such perfectly reasonably way), I think it
should also be a forgiving interface, and should accept reasonable
unambiguous alternatives, such as --foo=no instead of --foo=0.
For what it's worth, those are my rambling thoughts this morning.
--
Andy Dougherty doug...@lafayette.edu
Allison Randal
> On Tue, 1 May 2007, James Keenan via RT wrote:
>
>> On Tue Apr 10 01:45:31 2007, jri...@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.
> 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
James Keenan via RT
> 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.
>
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.
For at least the third of those tasks, that someone, currently, is me. If we choose to support
"yes" and "no" where "1" and "0" would suffice, then I have to write additional tests to test
that code. That's more work for me -- but it also means that you, the Parrot developer, have
to wait longer and longer for 'make test' to run.
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?
If the values available for a given option logically reduce to a Boolean, then reduce the
possible values to "1" and "0". Then, document them and test them.
kid51
Andy Dougherty
> 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 doug...@lafayette.edu