>>>> "sjt" == Stephen J Turnbull
>>>> "Malcolm" == Malcolm Purvis
Malcolm> Therefore below are various combinations that the patch
Malcolm> supports. Stephen, is this the behaviour that you
sjt> Yes, in all cases.
Oops, not quite true. This is not what I expect:
Malcolm> Given a complex option --with-complex with three values:
Malcolm> 'foo', 'bar' and 'baz' that have defaults of
Malcolm> and "" the shell variables under different conditions
Malcolm> 1) --with-complex not supplied:
I realized this when I looked closely at the result of "./configure"
and found that (1) Xft support wasn't checked for, and (2) ESD was
found and configured, despite being deprecated (defaults to "no").
(2) is a change in behavior of the configure script.
Malcolm> 2) --with-complex
In the latter case, note that the autodetect ("don't care") is forced
to "yes". This (IMO) should imply that failure to support that
feature is a fatal error in configuration.
In terms of the desiderata I wrote before,
(1) The last explicit setting of each option (foo or nofoo) wins.
(2) "all" or "none" as the first option in the list resets
defaults for all suboptions to the corresponding value; if
they come later they are ignored (maybe a warning is issued).
(3) "yes" uses the defaults coded in the XE_COMPLEX_ARG
declaration. (I don't care whether "yes" has to be alone or
could be used first in combination with explicit options.)
(4) "no" and "non" are abbreviations for "none". (This
little tricky, since "yes" has different semantics from
but I think it works correctly.)
(5) If the argument is missing, or none of "yes", "all", and
"none" appear in the first position, the semantics are like
(6) A default of "" means to autodetect.
I want to add
(7) For each option, the difference between "yes" and ""
is that failure to find the feature is a fatal configure error
(or at least results in a heavy-duty warning like the one for
(8) For the whole flag, the difference between "yes" and not
giving the flag at all is that in the former case "" (autodetect)
is promoted to "yes" for each option.
This means that defaulting to "yes" or "no" is a pretty strong
statement by the XEmacs developers. A default of "yes" is going to
cause an error unless support is found or the user explicitly
disables, while a default of "no" means the user has to take explicit
action to get the feature, even if proper support is available.
sjt> Yes, I will. configure is starting to shape up quite nicely,
I still think this is true, there's just more work to do. :-)
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.