Re: elc-files in distribution tar-ball can break build
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> Oh, that's our resident Mule Nazi, then. He believes it's OK to cause
> pain for non-Mule users [...]
pun aside - What is the story?
Because no-Mule XEmacs has no facilities for dealing with multibyte or
widechar charsets, no-Mule XEmacs can (Aidan would say "is likely to")
corrupt files encoded that way. Aidan takes the extreme position that
therefore no-mule XEmacs is fundamentally broken by design, and he has
no obligation to support it when he makes changes.
I disagree; on the one hand, no-mule XEmacs is a perfectly good binary
editor, and that works fine for some important special cases in text
editing. On the other, the fact that the changes he makes in Mule
affect the no-Mule build indicates to me that Mule assumptions about
implementation are leaking into more and more parts of XEmacs. I
think that is only going to make it harder to change the internal
encoding to Unicode, and harder in general to maintain XEmacs.
> I'm not comfortable messing with bytecomp.el, and he is
unlikely to
> have either the time or the inclination to fix this. So I think for
> the next beta I'm just going to go ahead and change to --with-mule=yes
> by default, and insert a warning about the .elcs in Installation for
> --without-mule builds, and note it in PROBLEMS.
Why not just not include them and let them be built as part of the
build process?
For several reasons. First:
It takes a little more time but it will always be right.
is actually false for repeated builds from the same source. If you do
a Mule build in-tree, then a no-Mule build, the same thing will
happen. If you have srcdir Mule builds and no-Mule builds using the
same source tree, either the Mule build will be buggy because no-Mule
can't compile those files correctly but there's no indication of the
problem, or the no-Mule build will fail in the same way. A warning
needs to be issued, or the no-Mule build should force "make beta"
somehow.
This is what I intend to do for Gentoo anyway. I can't see any
other good option.
That's the best option for distro builds, of course, and some distros
(Debian) require it as policy. But if (like Debian) you try to have
Mule and no-Mule binary package installations co-exist in the same
system, now you have to distribute separate Mule and no-Mule
"xemacs-common" packages; you can't just build a suite of binaries
with different features if the feature is Mule.
The other reasons for fixing this bug is that it *is* a bug.
1. Lisp should degrade gracefully in the presence of missing
features, with a "no such function" error. It shouldn't refuse to
work entirely.
2. Lisp should not behave differently when interpreted and compiled.
It's true that Mule is a special case: no other configurable feature
pervades all of XEmacs in that way. But special cases aren't special
enough to break these rules. It really should not be harmful to
distribute pre-built Lisp and Info, and that has been the traditional
format. Finally:
3. Completely removing no-Mule is still not really an option. There
are some use cases (processing gigabyte log files, for example)
where no-Mule is much faster. It's even possible to use a no-Mule
XEmacs to edit non-ASCII characters in UTF-8 files in a UTF-8
terminal window. It's about as pleasant as using say nano, and
the risk of corruption is high, but it's possible.
Regards,
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta