Re: [PATCH] Xft related configure option fixes.

Malcolm> Therefore below are various combinations that the patch Malcolm> supports. Stephen, is this the behaviour that you Malcolm> expect? 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 'yes', 'no' Malcolm> and "" the shell variables under different conditions Malcolm> are: Malcolm> 1) --with-complex not supplied: Malcolm> with_complex_foo="" Malcolm> with_complex_bar="" Malcolm> with_complex_baz="" I want with_complex_foo="yes" with_complex_bar="no" with_complex_baz="" 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. And for Malcolm> 2) --with-complex Malcolm> with_complex_foo=yes Malcolm> with_complex_bar=no Malcolm> with_complex_baz="" 2) --with-complex with_complex_foo=yes with_complex_bar=no with_complex_baz=yes 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 is a little tricky, since "yes" has different semantics from "all", 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 "yes". (6) A default of "" means to autodetect. I want to add (7) For each option, the difference between "yes" and "" (autodetect) 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 missing XPM). (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, sjt> IMO. 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.