Malcolm> It should be pointed out that this is slightly different Malcolm> behaviour from the normal argument case. In that case if Malcolm> --with-simple is not supplied then the shell variable Malcolm> with_simple is "". But the value for with_complex is "", just as in the simple argument case. I would say that any behavior we specify for defaults of with_complex_foo is an almost independent extension. True, we could specify more defaults in the True/False cases, but I think that violates the DRY (Don't Repeat Yourself) principle, and would depend on coders of options to follow policy to get consistent results. I would argue that in most cases the default for with_complex_foo should be "", in most of the rest (known bugs in the feature) it should be "no", and in a very few cases we could consider it being "yes". (For example, if we move image support configuration to a complex option --with-image-format, then Xpm and PNG support might want to default to yes. The ones that we currently scream about anyway.) I'm thinking about adding a XE_VALIDATE_COMPLEX_OPTION. The idea is that it would be used after completing detection of the features, and would do if "$test with_complex_foo" = "yes" -a "$have_complex_foo" != "yes"; then XE_DIE([Required complex foo support not available.]) fi and also loop over the complex foos and XE_DIE if the with_complex is yes, but all of the have_complex_foo are no. (Yes, I'm aware that we don't have consistent use of have_complex_foo. That's why I'm not doing it in the attachments, lotsa work. :-) Malcolm> My proposal was in line with the traditional behaviour Malcolm> but yours I think is better. Good. This one I definitely like. Malcolm> Your desiderata does not address this case: Malcolm> 4) --with-complex=bar Malcolm> with_complex_foo=no Malcolm> with_complex_bar=yes Malcolm> with_complex_baz=no I now think this behavior is incorrect, though not because it violates the POLA (I found it surprising, but that's quite likely because I did a lot of the work on the support for this feature). The argument is a little more subtle (and maybe questionable). In general we want XEmacs to have all the features configure can find. If a user or a distro wants to defeat some, fine. But let them do it explicitly. Surely you've seen the miles-long configure line that SuSE uses in bug reports? Mike hasn't complained, and I doubt he will, as long as our configure options are backward compatible with his script. I'd like to start moving more of the optional features to modules, which won't affect DIY users much, but will allow distros to include everything while reducing their REQUIRE dependency libraries to SUGGEST dependencies. So overall I think that we should default to autodetect (in configure option lingo, "") as much as possible. The above case is included in that preference. Malcolm> You came up with this requirement with discussing Malcolm> --with-error-checking a few months ago. The post can be Malcolm> found at: Malcolm> http://list-archive.xemacs.org/xemacs-beta/200510/msg00481.html Malcolm> Is this case still a requirement? No. If we think that behavior is appropriate we can set the defaults to no,no,no,no,no!, easy enough. Note that --with-error-checking is one of the few cases where setting the with_error_checking_foo defaults to yes makes a priori sense. So that's kind of an exceptional case. Here's code that implements what I'm proposing. The first attachment is "test.ac", which simply is the first part of configure.ac with my code substituted for XE_PARSE_COMPLEX_OPTION (nothing else needs to be touched, good job Malcolm!) plus a single complex option "quux". The second of course is the generated "test" script. The script doesn't generate any configuration, of course, it just echoes the values of the variables at the end. (test.ac does include your current version, commented out, for comparison. They're quite different, I got confused by shell quoting and ended up starting from scratch! :^) -- 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.