I need to actually look at the code, I'll get back to you this
evening. Regarding the design question:
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
Malcolm> Stephen, back to Jérôme Marant's original complaint.
Malcolm> Supplying a bare --with-xft still does not enable an form
Malcolm> of xft support, which I think is quite counter-intuitive.
Very true.
Malcolm> Are you sure you don't want --with-complex to be the
Malcolm> equivalent of --with-complex=all?
I'm sure. I definitely want the "no" in the default specification for
sound of native=detect, nas=detect, esd=no to be obeyed unless the
user explicitly specifies --with-sound=all or --with-sound=esd.
--with-sound shouldn't be enough to enable a feature that has been
known to cause crashes on some systems but to be safe or highly
desired by users on others.
I don't see any way to resolve this without more complexity in arg
processing.
One route is the one you implicitly took, which uses the yes and no
branches of XE_COMPLEX_ARG to compute whether to use the defaults and
how. The problem with that is redundancy. You not only need to write
the yes and no handling code correctly, you also need to fix the
documentation string to explain the details, and most developers will
need to make a substantial effort to figure out how all this works and
where they're supposed to make changes to change defaults (maybe even
you and me :-P).
The second route is to add an internal value "implicit" used only in
default specs for complex args. The semantics for each component
value are
no require the user to specify --with-feature=component
implicit if --with-feature is not specified, demote to no
if --with-feature is specified, auto-detect
(ignore failure to detect)
"" if --with-feature is not specified, auto-detect
(ignore failure to detect)
if --with-feature is specified, promote to yes
(failure to detect is fatal)
yes failure to detect is fatal
The reason to choose those semantics for implicit and "" is that this
is how "" behaves for boolean features (since for those --with-feature
implies yes). (I generally think of XE_COMPLEX_ARG as a way to group
a bunch of related boolean features.)
In this scheme, a default spec of either with_xft=implicit,no,no,no or
with_xft=implicit,implicit,implicit,implicit makes sense, I think. In
general the use of "" would be rare, as would yes.
A third possibility is that the semantics given to "" above might not
be very useful. So omit the implicit value and give "" the semantics
of implicit. Substitute "" for implicit in the examples above. Both
of these handle the Xft case satisfactorily. Do you think one or the
other is general enough, or should we use the yes/no branches in the
ARG processing to handle it?
I just noticed that in both cases you'd have the problem that if the
default was with_xft=implicit,implicit,implicit,implicit and configure
failed to find fontconfig, the configure would succeed and silently
omit Xft support. So I guess either way we need code to make sure
that at least one of the desired options succeeds. I think that could
be implemented with a have_xft variable that gets set to yes anytime
one of the suboptions (eg have_xft_tabs) does.
Two questions that don't need to be settled now, but occurred to me
while thinking about it:
I think there _always_ ought to be separate with_feature and
have_feature variables, with an automatic consistency check (ie, for
all features XE_DIE if with_feature=yes && have_feature=no). Do you
agree?
About the names, how would you feel about changing the names of the
macros from XE_KEYWORD_ARG and XE_COMPLEX_ARG to XE_RADIO_ARG and
XE_CHECKBOX_ARG respectively? Or something like that (eg, CHOICE and
SET). To my mind, KEYWORD and COMPLEX could almost be exchanged.
They don't really suggest the semantics of "one of many" and "several
of many".
--
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.