>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
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.
--
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.