Re: enable-foo vs. with-foo is illogical

Ben> we have --enable-database={berkdb,...}, --enable-sound={nas,esd,...} I wouldn't get to hung up on the idea that referencing an external library must mean that --with has be used instead of --enable. When I assigned the new flags I interpreted the definitions that Hrvoje posted as followed: - If the feature changed what I thought what the nature of XEmacs was then is was given --enable, even if it also referred to external libraries. - If the feature was more of an implementation detail of XEmacs' nature then it was with --with. eg, - XEmacs with MULE or bignums is a different beast to one without either, so both get --enable. - XEmacs with widgets is different to XEmacs without and gets --enable, but the choice of toolkit that implements that widgets doesn't changes XEmacs' nature so it given --with. That's not so say that my choices are perfect. Ben> How about --with-toolbars but --enable-menubars? It's actually --enable-toolbars. The --with-toolbars is a typo in the help string. To answer Olivier's question, aliasing --with and --enable wouldn't be too difficult with a bit of macro magic but doing so would would tie us into knowing the implementation of yet another autoconf macro. We currently only override one autoconf macro (AC_LANG(C)) and I'd like to avoid doing more if ai all possible because it this sort of detailed knowledge that made moving up from autoconf 2.13 so hard in the first place. However, it the new options are genuinely causing confusion, and it is not just a case of muscle memory typing in the old options, I'll happily produce an aliasing patch. Malcolm -- Malcolm Purvis <malcolmp(a)xemacs.org&gt;