Aidan, I think the runtime use of mule packages should not be
conditionalized on their availability, but rather on whether the
running XEmacs has (featurep 'mule) available.
I built myself a non-MULE cvs HEAD XEmacs and can't send mail with it,
because of this:
Aidan Kehoe <kehoea(a)parhasard.net> writes:
Ar an triú lá déag de mí Márta, scríobh Steve Youngs:
> * 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
> > + (autoload 'latin-unity-representations-present-region
> > + (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?
Everything inside that eval-when-compile is there to shut up the byte
compiler. You can take it all out, the patch works fine. You can compile the
thing with a non-Mule XEmacs, or with a XEmacs which doesn~t have the
latin-unity package available, and the patch works fine. latin-unity is
still checked for at runtime, and used if available.
When Katsumi Yamaoka added that clause, he should perhaps have added a
comment to the effect that that eval-when-compile was only to shut up the
> This change means the Gnus package will have a dependence on the
> latin-unity package.
Only if you add that dependency. Otherwise, it~ll build and install fine
without latin-unity or Mule being available.