6:03 p.m.
Hi!
XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i386-unknown-freebsd4.3, Mule)
of Thu May 3 2001 on lamia.LF.net
The byte-compiler-test fail at the moment:
Testing
/usr/local/users/support/nk/cvs/xemacs/tests/automated/byte-compiler-tests.el
Unexpected error (void-function defadvice) while executing interpreted
code.
Test suite execution aborted.
Unexpected error (void-variable message) while executing byte-compiled
code.
Test suite execution aborted.
byte-compiler-tests.el: No tests run
Test suite execution failed unexpectedly.
norbert.
2:40 p.m.
>>>> "NK" == Norbert Koch <nk(a)LF.net>
writes:
NK> Unexpected error (void-function defadvice) while executing
NK> interpreted code.
These are functions defined in packages.
Are you perhaps using --with-prefix=no? That has caused this problem
in the past. (With that setting, installed packages cannot be found
from a run-in-place xemacs -- including during the build process.)
--
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."
2:57 p.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hi Stephen.
>>>>> "NK" == Norbert Koch <nk(a)LF.net>
writes:
NK> Unexpected error (void-function defadvice) while executing
NK> interpreted code.
These are functions defined in packages.
Are you perhaps using --with-prefix=no? That has caused this problem
in the past. (With that setting, installed packages cannot be found
from a run-in-place xemacs -- including during the build process.)
No, I've got a prefix defined. Could it be a problem that I build
xemacs-packages out of CVS using a make install, ie I've got a
symlinked package tree?
The call to configure is
./configure --prefix=/sw/i386_fbsd4/xemacs-21.5 \
'--site-includes=/client/include /usr/local/include' \
'--site-libraries=/client/lib /usr/local/lib' \
--use-union-type --with-mule --pdump
norbert.
3:13 p.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
>>>> "NK" == Norbert Koch <nk(a)LF.net>
writes:
NK> The byte-compiler-test fail at the moment:
NK> Testing
NK> /usr/local/users/support/nk/cvs/xemacs/tests/automated/byte-compiler-tests.el
NK> Unexpected error (void-function defadvice) while executing interpreted code.
> Are you perhaps using --with-prefix=no? That has caused this
> problem in the past. (With that setting, installed packages
> cannot be found from a run-in-place xemacs -- including during
> the build process.)
NK> No, I've got a prefix defined.
--with-prefix=no is compatible with --prefix=..., it says "don't build
$prefix into the executable".
NK> Could it be a problem that I build xemacs-packages out of CVS
NK> using a make install, ie I've got a symlinked package tree?
Don't think so.
Where exactly are your packages? What does `src/xemacs --debug-paths'
say?
We're looking for /sw/i386_fbsd4/xemacs-21.5 in emacs-roots, and the
package directories relative to that in load-path. Two more tries: If
they are relative to (eg) /sw/i386_fbsd4/xemacs/, they won't be found.
If this has suddenly stopped working with the move to 21.5, is it
possible that you've started a new source tree, and the old one had a
symlink $srcdir/xemacs-packages -> /path/to/xemacs-packages?
AFAIK, although XEmacs doesn't like to keep symlinks around, it
achieve that goal by chasing them until they hit a real target, not by
discarding them. So they should end up in load-path and be found, if
they're rooted in ~/.xemacs, $executable/../, $prefix/, or relative to
something in a --package-path directive to configure. That's all the
package-root candidates AFAIK.
Michael?
--
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."
7:38 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hi!
--with-prefix=no is compatible with --prefix=..., it says
"don't build
$prefix into the executable".
Ah, haven't known that.
NK> Could it be a problem that I build xemacs-packages out of
CVS
NK> using a make install, ie I've got a symlinked package tree?
Don't think so.
Where exactly are your packages? What does `src/xemacs --debug-paths'
say?
Thanks for the pointer. It looks strange.....
I've got
/sw/i386_fbsd4/xemacs-21.5/lib/xemacs
as product of a make install out of xemacs-packages
Local.rules define
XEMACS_STAGING = /sw/i386_fbsd3/xemacs-21.5/lib/xemacs/xemacs-packages
MULE_STAGING = /sw/i386_fbsd3/xemacs-21.5/lib/xemacs/mule-packages
Now, the paths look like
/usr/users/support/nk/cvs/xemacs/src $ ./xemacs --debug-paths
emacs-roots:
("/usr/users/support/nk/cvs/xemacs/" "/sw/i386_fbsd4/xemacs-21.5/")
configure-package-path:
nil
early-packages and early-package-load-path:
nil
nil
late-packages and late-package-load-path:
("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/"
"/usr/users/support/nk/cvs/xemacs-packages/"
"/usr/users/support/nk/cvs/xemacs-packages/comm/"
"/usr/users/support/nk/cvs/xemacs-packages/games/"
"/usr/users/support/nk/cvs/xemacs-packages/libs/"
"/usr/users/support/nk/cvs/xemacs-packages/mule/"
"/usr/users/support/nk/cvs/xemacs-packages/oa/"
"/usr/users/support/nk/cvs/xemacs-packages/os/"
"/usr/users/support/nk/cvs/xemacs-packages/prog/"
"/usr/users/support/nk/cvs/xemacs-packages/wp/")
("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/edict/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/egg-its/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/leim/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/locale/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/lookup/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/mule-base/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/skk/")
last-packages and last-package-load-path:
nil
nil
lisp-directory:
"/usr/users/support/nk/cvs/xemacs/lisp/"
mule-lisp-directory:
"/usr/users/support/nk/cvs/xemacs/lisp/mule/"
Info-directory-list:
("/usr/users/support/nk/cvs/xemacs/info/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/info/"
"/usr/local/info" "/usr/share/info")
exec-directory:
/usr/users/support/nk/cvs/xemacs/lib-src/
exec-path:
("/usr/users/support/nk/bin/" "/client/bin/"
"/usr/local/bin/" "/bin/" "/usr/bin/"
"/usr/X11R6/bin/" "/prj/bin/" "/client/sbin/"
"/sbin/" "/usr/sbin/" "/etc/" "/bin/"
"/usr/users/support/nk/cvs/xemacs/lib-src/")
doc-directory:
"/usr/users/support/nk/cvs/xemacs/lib-src/"
data-directory:
"/usr/users/support/nk/cvs/xemacs/etc/"
data-directory-list:
("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/app-defaults/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/mule/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/mule-doc/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/skk/"
"/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/start-files/"
"/usr/users/support/nk/cvs/xemacs/etc/")
It's funny, the mule-packages lie in the destination emacs-root, while
the xemacs-packages are found in the source emacs-root.
Hmm, strange, well for me, that is.
As Steve has pointed out, I would also have thought that the checks
run without any packages installed, because this inherently causes a
first installation of the xemacs core to fail.
norbert.
8:29 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
>>>> "Norbert" == Norbert Koch <nk(a)LF.net>
writes:
Norbert> It's funny, the mule-packages lie in the destination emacs-root, while
Norbert> the xemacs-packages are found in the source emacs-root.
Norbert> Hmm, strange, well for me, that is.
Do xemacs-packages exit in the destination emacs-root?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
9:04 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hi!
>>>>> "Norbert" == Norbert Koch
<nk(a)LF.net> writes:
Norbert> It's funny, the mule-packages lie in the destination emacs-root, while
Norbert> the xemacs-packages are found in the source emacs-root.
Norbert> Hmm, strange, well for me, that is.
Do xemacs-packages exit in the destination emacs-root?
/usr/users/support/nk/cvs/xemacs-packages
is the top-level of my CVS package sources. There, as you know, we
have another structure.
I don't grok the fact that mule-package paths are okay,
xemacs-package paths are not.
Where would I look for this? Should I try to fix package paths during
configure?
Thanks,
norbert.
9:23 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
>>>> "norbert" == Norbert Koch <nk(a)LF.net>
writes:
norbert> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
writes:
norbert> Hi!
>>>>>> "Norbert" == Norbert Koch
<nk(a)LF.net> writes:
>
Norbert> It's funny, the mule-packages lie in the destination
emacs-root, while
Norbert> the xemacs-packages are found in the source emacs-root.
>
Norbert> Hmm, strange, well for me, that is.
>
>> Do xemacs-packages exit in the destination
emacs-root?
norbert> /usr/users/support/nk/cvs/xemacs-packages
norbert> is the top-level of my CVS package sources. There, as you know, we
norbert> have another structure.
norbert> I don't grok the fact that mule-package paths are okay,
norbert> xemacs-package paths are not.
That's because XEmacs thinks your checked-out CVS sandbox *is* the
xemacs-package hierarchy while it isn't. (Ben wanted this feature
very badly.)
The solution is to move it somewhere else or to make a symlink from
the actual xemacs-package hierarchy to inside your build directory.
For example, my build directory looks like this:
-rw-r--r-- 1 sperber PUstaff 2873 Apr 30 15:22 Installation
-r--r--r-- 1 sperber PUstaff 11887 Apr 30 15:22 Makefile
-rw-r--r-- 1 sperber PUstaff 25605 Apr 30 15:22 Makefile.in
-rw-r--r-- 1 sperber PUstaff 105298 Apr 30 15:22 config.log
-rwxr-xr-x 1 sperber PUstaff 55979 Apr 30 15:22 config.status*
lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 etc＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/etc
lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 info＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/info
drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:29 lib-src/
lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 lisp＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/lisp
drwxr-xr-x 2 sperber PUstaff 2048 Apr 13 11:52 lock/
drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:24 lwlib/
lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 man＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/man
lrwxr-xr-x 1 sperber PUstaff 73 Apr 13 12:03 site-packages＠ ->
/afs/informatik.uni-tuebingen.de/share/xemacs-21/lib/xemacs/site-packages
drwxr-xr-x 2 sperber PUstaff 6144 Apr 30 15:29 src/
lrwxr-xr-x 1 sperber PUstaff 64 Apr 13 11:52 tests＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/tests
lrwxr-xr-x 1 sperber PUstaff 75 Apr 13 12:03 xemacs-packages＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-packages/staging
Everything except site-packages and xemacs-packages was installed
automatically by configure and make.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
9:18 p.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Ah, I simply love the Internet. It's cute talking to a guy located
but 70 km away via a server in the States (It only takes 19 hops to get
there :-)
[...]
norbert> I don't grok the fact that mule-package paths are
okay,
norbert> xemacs-package paths are not.
That's because XEmacs thinks your checked-out CVS sandbox *is* the
xemacs-package hierarchy while it isn't. (Ben wanted this feature
very badly.)
The solution is to move it somewhere else or to make a symlink from
the actual xemacs-package hierarchy to inside your build directory.
For example, my build directory looks like this:
-rw-r--r-- 1 sperber PUstaff 2873 Apr 30 15:22 Installation
-r--r--r-- 1 sperber PUstaff 11887 Apr 30 15:22 Makefile
-rw-r--r-- 1 sperber PUstaff 25605 Apr 30 15:22 Makefile.in
-rw-r--r-- 1 sperber PUstaff 105298 Apr 30 15:22 config.log
-rwxr-xr-x 1 sperber PUstaff 55979 Apr 30 15:22 config.status*
lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 etc＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/etc
lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 info＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/info
drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:29 lib-src/
lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 lisp＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/lisp
drwxr-xr-x 2 sperber PUstaff 2048 Apr 13 11:52 lock/
drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:24 lwlib/
lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 man＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/man
lrwxr-xr-x 1 sperber PUstaff 73 Apr 13 12:03 site-packages＠ ->
/afs/informatik.uni-tuebingen.de/share/xemacs-21/lib/xemacs/site-packages
drwxr-xr-x 2 sperber PUstaff 6144 Apr 30 15:29 src/
lrwxr-xr-x 1 sperber PUstaff 64 Apr 13 11:52 tests＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/tests
lrwxr-xr-x 1 sperber PUstaff 75 Apr 13 12:03 xemacs-packages＠ ->
/afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-packages/staging
Everything except site-packages and xemacs-packages was installed
automatically by configure and make.
Allright, I think, I've got it, at least I don't see the error
messages any longer.
CWD = /usr/local/users/support/nk/cvs/xemacs
which is the toplevel of my xemacs source tree. If I create the two
symlinks
mule-packages -> /sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages
xemacs-packages -> /sw/i386_fbsd4/xemacs-21.5/lib/xemacs/xemacs-packages
everything runs smoothly. I only wonder, why I (or others) haven't
noticed this, err, feature, by now. Or should I have R some FM?
Thanks for the help,
norbert.
4:30 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
>>>> "nk" == Norbert Koch <nk(a)LF.net>
writes:
nk> everything runs smoothly. I only wonder, why I (or others)
nk> haven't noticed this, err, feature, by now.
It has been noticed, in various contexts. XEmacs is simply not as
flexible in adapting to random user setups as it used to be.
Partly Michael did some pruning away of some "backwards compatibility"
code a couple of months ago. This may have for some reason suddenly
manifested in your most recent builds.
nk> Or should I have R some FM?
Yeah, probably. However, I know there is some documentation, but it's
not yet as complete and easy to find as we'd like. I think the
"canonical setup" is by now pretty well explained in
"README.packages"
and in the Texinfo docs, but the theory and troubleshooting are not.
--
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."
8:47 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
>>>> "NK" == Norbert Koch <nk(a)LF.net>
writes:
NK> It's funny, the mule-packages lie in the destination
NK> emacs-root, while the xemacs-packages are found in the
NK> source emacs-root.
I guess this could be due to symlinks, then. Note that no actual
packages are being found (except in Mule). Do you have any Mule
packages in cvs?
NK> As Steve has pointed out, I would also have thought that the
NK> checks run without any packages installed, because this
NK> inherently causes a first installation of the xemacs core to
NK> fail.
No, "make install" does not run "make check". Shouldn't, anyway.
So
this doesn't prevent installation.
These checks _definitely_ will not run without packages available,
because the libraries that define those functions are not in core. I
don't know how to deal with this. I think probably the
tests/automated stuff should condition-case the requires, and if they
fail run a limited subset or tests, and warn.
I don't think that's a bad thing; if packages exercise some part of
xemacs well, I don't see why we shouldn't use them in testing (if the
alternative is that we don't write any tests).
But that's not my job at the moment.
--
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."
9:05 a.m.
New subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hi!
I guess this could be due to symlinks, then. Note that no actual
packages are being found (except in Mule). Do you have any Mule
packages in cvs?
Yes, I've got the whole package tree lying around as in
cvs checkout xemacs-packages
norbert.
3:51 p.m.
|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>>"NK" == Norbert Koch <nk(a)LF.net>
writes:
NK> Unexpected error (void-function defadvice) while executing
NK> interpreted code.
SJT> These are functions defined in packages.
SJT> Are you perhaps using --with-prefix=no? That has caused this problem
SJT> in the past. (With that setting, installed packages cannot be found
SJT> from a run-in-place xemacs -- including during the build process.)
XEmacs should build fine without _any_ packages installed. I haven't
done it for a while, so I'll test and let you know if it still works.
And if all the tests pass.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8598
days inactive
8601
days old
12 comments
4 participants
participants (4)
-
Michael Sperber -
Norbert Koch -
Stephen J. Turnbull -
Steve Youngs