Re: [issue] ./configure --prefix=$prefix --infodir=$prefix/share/info broken
Ville Skyttä writes:
On Saturday 14 March 2009, Michael Sperber wrote:
> That's right. The problem is that configure doesn't
tell me (to my
> knowledge) whether the user did define it, or whether configure is just
> telling you the default.
It doesn't. For XE_MERGED_ARGs it would be easy to add in the m4
definition. For the *dir variables, which are mostly builtin to
autoconf, initialize each to "xe_placeholder_for_builtin_options",
then add
if test $OPTION=xe_placeholder_for_builtin_options; then
OPTION_user_defined=no
OPTION=DEFAULT_VALUE_FOR_OPTION
else
OPTION_user_defined=yes
fi
for each OPTION at about where the stray 'with_dragndrop_default="no"'
is now (so that it comes after the built-in options processor).
I think there's a bunch of things in configure.ac that should
just
go away. We use autoconf, so we should really just use it and not
fight against how it works without a very good reason.
I disagree. autoconf is nowhere near powerful enough to do what we
need it to do in terms of options processing, and it gets weaker with
every release as they add more checks and more bogus runtime warnings.
That's where most of the "fighting" is happening: trying to allow
people to specify stuff without having to add millions of additional
options.
And in the places we want to kludge around its usual behavior, the
wanted behavior and the reason for it needs to be documented. I
could spend some time trying to clean things up but without
documentation why the kludges exist, doing so would lead to
"bikeshed discussions".
Examples of undocumented differences? I hope you're not referring to
XE_MERGED_ARG and XE_COMPLEX_OPTION. (You're welcome to argue they're
unnecessary, but IMO they are copiously commented and include rationale,
which is not all that difficult to guess in the first place.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta