1:18 a.m.
I've always build w/o mule, but a colleague needs mule
he's building his own executable, but I thought we might as well share the
same packages tree, since we saw that the mule-sumo tarball just has the
extra mule stuff in it - it un-tars nicely into its own mule-packages
subdir in lib/xemacs, parallel to the xemacs-packages I was already using
but now when I start my non-mule xemacs I see these warnings:
(1) (warning/warning) Autoload error in:
/usr/net/rnd/lib/xemacs/mule-packages/lisp/skk/auto-autoloads:
Cannot open load file: mule
(2) (warning/warning) Autoload error in:
/usr/net/rnd/lib/xemacs/mule-packages/lisp/lookup/auto-autoloads:
Cannot open load file: mule
is this just one of those "don't do that" things, or should this be ok?
that is, should we just ignore the warnings, or do they indicate some
deeper badness?
thx,
--
John A. Turner, Ph.D. Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY 10601
http://www.blueskystudios.com/ (914) 259-6319
6:48 p.m.
On Wed, 18 Apr 2001, John A. Turner wrote:
he's building his own executable, but I thought we might as well
share the
same packages tree, since we saw that the mule-sumo tarball just has the
extra mule stuff in it - it un-tars nicely into its own mule-packages
subdir in lib/xemacs, parallel to the xemacs-packages I was already using
but now when I start my non-mule xemacs I see these warnings:
(1) (warning/warning) Autoload error in:
/usr/net/rnd/lib/xemacs/mule-packages/lisp/skk/auto-autoloads:
Cannot open load file: mule
Unfortunately, I think two separate package trees for mule and non-mule
xemacses is required. It's not hard to solve with symlinks, but remember
to use proper configure flags on one of the XEmacses.
This is quite bad IMO, the non-mule XEmacs simply shouldn't load packages
from the mule-packages/ directory, this would make it possibly to share
the xemacs package tree.
7:12 p.m.
>>>> "SJ" == Simon Josefsson
<jas(a)extundo.com>:
SJ> Unfortunately, I think two separate package trees for mule and non-mule
SJ> xemacses is required. It's not hard to solve with symlinks, but remember
SJ> to use proper configure flags on one of the XEmacses.
so far sharing trees seems to be fine for both mule and non-mule, after
re-building the non-mule with
--package-path=/usr/net/rnd/lib/xemacs/xemacs-packages
instead of
--package-path=/usr/net/rnd/lib/xemacs
-JT
5:18 a.m.
>>>> "SJ" == Simon Josefsson
<jas(a)extundo.com>:
SJ> Unfortunately, I think two separate package trees for mule and
SJ> non-mule xemacses is required.
It shouldn't be; it at least is designed so that mule-packages should
not be searched by a no-mule XEmacs. Whether the implementation is
complete I don't know, I always use Mule so I don't run into problems.
Sigh; yet another configuration variation I really should be building
and testing....
>>>> "John" == John A Turner
<turner(a)blueskystudios.com> writes:
John> so far sharing trees seems to be fine for both mule and
John> non-mule, after re-building the non-mule with
John> --package-path=/usr/net/rnd/lib/xemacs/xemacs-packages
I don't think you can rely on this working ofr future versions of
XEmacs. Michael Sperber has been insisting on simplifying the search
path for libraries, and codifying the structure under the various
"roots" where libraries can be found.
In particular, to implement "no-mule-xemacs doesn't search
mule-packages", the root would have to be /usr/net/rnd/lib/xemacs and
then xemacs-packages, (if mule) mule-packages, and (optionally)
site-packages would be searched, each to a specific depth:
lisp/$PACKAGE/$LIBRARY.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
11:55 a.m.
First off, please accept my apologies for taking so long to respond to
this.
|--==> "JAT" == John A Turner <turner(a)blueskystudios.com> writes:
JAT> but now when I start my non-mule xemacs I see these warnings:
JAT> (1) (warning/warning) Autoload error in:
JAT> /usr/net/rnd/lib/xemacs/mule-packages/lisp/skk/auto-autoloads:
JAT> Cannot open load file: mule
This definitely shouldn't happen. A non-Mule XEmacs won't see the
packages in ./mule-packages/. Or, at least it won't by default.
What's in your load-path?
Could we see your:
~/.emacs or ~/.xemacs/init.el
M-x describe-installation
please.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
7:32 p.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org>:
SY> This definitely shouldn't happen. A non-Mule XEmacs won't see the
SY> packages in ./mule-packages/. Or, at least it won't by default.
SY>
SY> What's in your load-path?
SY>
SY> Could we see your:
SY>
SY> ~/.emacs or ~/.xemacs/init.el
SY> M-x describe-installation
SY>
SY> please.
after re-building the non-mule with
--package-path=/usr/net/rnd/lib/xemacs/xemacs-packages
instead of
--package-path=/usr/net/rnd/lib/xemacs
though in another msg in that thread SJT said he didn't think this was the
best solution... however, since the above cured that particular itch, I
stopped scratching it...
-JT
8386
days inactive
8414
days old
5 comments
4 participants
participants (4)
-
John A. Turner -
Simon Josefsson -
Stephen J. Turnbull -
Steve Youngs