VETO
* Aidan Kehoe <kehoea(a)parhasard.net> writes:
+(eval-when-compile
+ (autoload 'latin-unity-massage-name "latin-unity")
+ (autoload 'latin-unity-maybe-remap "latin-unity")
+ (autoload 'latin-unity-representations-feasible-region "latin-unity")
+ (autoload 'latin-unity-representations-present-region "latin-unity")
+ (defvar latin-unity-coding-systems)
+ (defvar latin-unity-ucs-list))
This scares the shit out of me. How is this a good thing? How will
PUI + non-Mule XEmacsen cope with this?
This change means the Gnus package will have a dependence on the
latin-unity package.[1] That means that when someone running a non-Mule
XEmacsen tries to do the right thing in PUI and selects to
install/upgrade their Gnus package and then hits `r' to "Add Required
Packages", PUI will dutifully add latin-unity. The problem with that
is that non-Mule XEmacsen _CANNOT_ install mule packages.
And what about people trying to build packages with a non-Mule XEmacs?
They'll lose too. They won't be able to build Gnus because
`BUILD_WITHOUT_MULE' will be `t' and they won't have access to the
latin-unity package.
And aren't latin-unity/mule-ucs a big no no for 21.5? Maybe it's just
mule-ucs, I'm not sure?
I'm sorry, Aiden, but I just can't see how I can accept this patch in
its current state.
It _might_ be possible if those autoloads are wrapped in...
(when (featurep 'mule)
...)
And then in the Makefile...
ifeq ($(BUILD_WITHOUT_MULE),)
REQUIRES += latin-unity
endif
Yes, that could work, I think. Aiden, how does that sit with you?
Footnotes:
[1] Yes I see it is a compile-time dependence and not a run-time one,
but PUI doesn't make that distinction.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve(a)sxemacs.org>---|