Re: [PATCH] Xft related configure option fixes.

Malcolm> The specifications for complex arguments have evolved Malcolm> over the last few months and are not well documented. I want, and I think it's consistent with past behavior and what users expect as expressed in bug reports: (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. BTW your new wording "Invalid option supplied. Valid values for the [$2] option are: $_[$1]_types. A prefix of \"no\" will turn an option off. Options not given are set to off. Without an argument the default is $_[$1]_default. If the first option is \`all' or \`none' then all options are turned on or off." could be taken to mean that an initial all or none forces the values of the options to be all yes or all no, and trailing options have no effect. Malcolm> Therefore below are various combinations that the patch Malcolm> supports. Stephen, is this the behaviour that you Malcolm> expect? Yes, in all cases. Malcolm> Can you also check that I haven't broken the other Malcolm> complex arguments? Yes, I will. configure is starting to shape up quite nicely, IMO. -- 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.