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

>>>>>"Ben" == Ben Wing <ben(a)xemacs.org&gt; writes: >>>>> >>>>> Ben> Malcolm Purvis wrote: >> - 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. I think that's reasonable in theory, but pragmatically it has two problems. First, many people take the Autoconf scheme seriously. Second, even without that bias, people will have varying intuitions about "nature of XEmacs" vs. "implementation detail." Ben> [1] this distinction has little relevance to the "feature" vs Ben> "package" distinction. N.B. Malcolm explicitly disclaims following that rule. Ben> [2] i can't follow the logic of many of the choices. why Ben> --enable-sound but --with-png? what's the difference between Ben> sound and graphics? and --with-x but --enable-database? Is Ben> database support really more "fundamental" than X support? I'm not sure offhand, but ISTR these particular examples have to do with my hack to support multiple independent ways of providing a class of feature. So there's a local Autoconf macro that allows you to define a feature "foo" that can be supported with "bar" or "baz". It automatically supports "all", "none", and "no-OPTION" to turn off OPTION as a comma-separated list. IIRC, I did this only for --enable-foo which was bogus. Ben> and --enable-quick-build certainly doesn't belong. Well, --enable is the obvious correct choice for quick-build according to the Autoconf scheme, since it doesn't require any software not provided in the XEmacs sources. Ben> it really seems that there's no non-arbitrary way to divide Ben> up the options. I think everybody agrees with that. The question is more (1) whether we can be consistent enough without a macro aliasing --with to --enable, and (2) if not, if that's worth doing, and (3) if the answers are "no" and "no", what else can we do? FWIW, my answer to (1) is "yes", and (2) is "no". I don't really have a good answer to (3). The rule I propose for (1) is "If it requires installing other software to be linked with XEmacs on one or more officially supported platforms, it's '--with', otherwise, it's '--enable'." Modules can always be directly linked to XEmacs, so evaluate the rule at --disable-modules. So it's --enable-quick-build and --with-png. True, many platforms come with X11 installed, but Mac OS X and Windows don't (and most Linux distros require installing the dev packages), so it's --with-x11. The main one that I find confusing is widgets. Should it be --enable-widgets --with-athena=3d, or should it be --with-widgets=athena --with-athena=3d? I tend to prefer the former, on the grounds that mixing and matching widget sets is ugly and bug-prone, but in theory you can mix Athena with Motif, and we do have the Lucid "native" widgets like the menubar. So as a practical matter we may need to allow different widget sets for menubar, dialogs, scrollbars, and widgets, implying --with-menubar, --with-dialogs, --with-scrollbars, and --with-widgets.