ST> ./configure --with-sound=native,nas,noesd does not disable ESD. ST> You need to do ST> ./configure --with-sound=none,native,nas,noesd ST> or ST> ./configure --with-sound=none,native,nas ST> to get the configuration I want. ST> Why is the default "native, esd" and not "everything we can detect"? Sound support needs some improvement. The current configure stuff is way too hard to understand. For starters, there's this patch to enable --with-sound=nas,noesd to work. Untested, but must be correct. 1999-12-07 Martin Buchholz <martin(a)xemacs.org&gt; * configure.in (--with-sound): Variable with_esd was mispelled. --- configure.in 1999/12/07 07:08:59 1.111.2.52 +++ configure.in 1999/12/08 07:35:26 ＠＠ -618,7 +618,7 ＠＠ nonas ) with_nas_sound=no ;; esd ) with_esd=yes ;; - noesd ) with_esh=no ;; + noesd ) with_esd=no ;; * ) bogus_sound=yes ;; esac

ST> Why is the default "native, esd" and not "everything we can ST> detect"? mb> How do people feel about this more comprehensible user mb> interface: mb> --with-nas-sound=yes|no (default autodetect) mb> --with-esd-sound=yes|no (default autodetect) mb> --with-native-sound=yes|no (default autodetect) Bletch, but I could live with it. I like the current format. But I would parse it as follows. --with-sound takes an argument which is a comma-separated list. o The list may be the single word "none" (or "no"), in which case no sound capability is built in. o The list may contain the types "native", "nas", "esd", ..., in which case the specified type is tested, and if not found, configure barfs. o The list may contain a type prefixed by "no" ("noesd", etc), in which case the type is not tested for and siliently ignored (even with "auto"; in fact, it's a noop without "auto"). o The list may contain the word "auto", in which case all types not explicitly mentioned are tested for. Types which are not explicitly requested and not found are silently ignored; types which are explicitly requested and not found still cause configure to barf. o The list may be the single word "yes", which is the same as "auto" (all types are tested), except that if no sound is found, configure barfs. I would have barf == abort, I think. Under this interpretation, --with-sound=native,esd gives the user what he expects, no matter what additional types of sound we add. Specified as logic, it looks complex, but I think the result is intuitive for the user. This would generalize to other multioptional features such as database interfaces, input methods, etc. Of course, this doesn't work intuitively if there are complex conflicts (a mutually exclusive set is not really a problem but something where you can have native sound plus one of nas and esd but not both is), but nothing would be intuitive then, I think. In a case like that I would have configure abort, with a message "You must explicitly specify one but not both of esd and nas", rather than silently default the conflict to one or the other. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."