12:08 a.m.
Hi,
All the mule build of the smoketest now fails due to problem when
building mew-ja.info. It has been so for quite some time, and
mysterious since it builds fine on my other machines, and I have had
no clue why this happens until now.
For compiling mew-ja.info texinfo-format-buffer is used. In the
package smoketest this fails due to "Symbol's function definition is
void: regexp-opt". Thus indicating that regexp-opt isn't loaded
properly.
How can that be so and what can be done about it?
In XEmacs.rules the load path for the operation is set to this:
-eval '(setq load-path (append
(list "$(XEMACS_PACKAGES_BASE)/xemacs-packages/texinfo"
"$(XEMACS_PACKAGES_BASE)/xemacs-packages/text-modes"
"$(XEMACS_PACKAGES_BASE)/xemacs-packages/xemacs-base")
load-path))' -l informat -l texinfmt -f texinfo-format-buffer
So the load-path for the XEmacs binary is appended with a few selected
directories. In the smoketest case there isn't much in the load-path
since there are no packages installed. It is built from a completely
clean environment.
(This can easily be simulated by moving away the xemacs-packages and
mule-packages from the load-path and then doing a
make autoload; cd xemacs-packlages/mew; make
This will produce the error seen in the package smoketest.)
My guess is that the XEmacs.rules line above works bad together with
the
(eval-when-compile (require 'tex-mode) (require 'cl) (require
'regexp-opt))
in texinfo.el.
I can't figure out from the documentation for eval-when-compile how it
is supposed to work, will regexp-opt be loaded when a non compiled
texinfo.el is loaded or not? However adding
'-l regexp-opt' (to the line in XEmacs.rules above)
makes building mew-ja.info work as expected.
Yours
--
%% Mats
7:36 a.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> "Symbol's function definition is void: regexp-opt".
This probably is due to some rearranging that Ben did; something is
weird with autoloads in regexp-opt.
Ben, what's going on here?
Mats> (eval-when-compile (require 'tex-mode) (require 'cl)
Mats> (require 'regexp-opt))
Mats> in texinfo.el.
Mats> I can't figure out from the documentation for
Mats> eval-when-compile how it is supposed to work, will
Mats> regexp-opt be loaded when a non compiled texinfo.el is
Mats> loaded or not?
No, it will not. The reason for the eval-when-compile is that if you
compile without loading regexp-opt first, there will be unexpanded
macro calls in the byte code, which will fail (macros are supposed to
be expanded before compiling).
However, you don't want to load unneeded cruft, so when calling
functions OR macros from texinfo uncompiled we depend on autoload to
make sure the library is loaded when needed.
Mats> However adding
Mats> '-l regexp-opt' (to the line in XEmacs.rules above)
Mats> makes building mew-ja.info work as expected.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:36 a.m.
-----Original Message-----
From: Stephen J. Turnbull [mailto:turnbullīŧ sk.tsukuba.ac.jp]
On Behalf Of Stephen J. Turnbull
Sent: Friday, January 21, 2005 1:36 AM
To: Mats Lidell
Cc: xemacs-beta(a)xemacs.org; ben(a)xemacs.org
Subject: Re: Package Smoketest and the building of mew-ja.info
>>>>> "Mats" == Mats Lidell <matsl(a)xemacs.org> writes:
Mats> "Symbol's function definition is void: regexp-opt".
This probably is due to some rearranging that Ben did;
something is weird with autoloads in regexp-opt.
Ben, what's going on here?
Mats> (eval-when-compile (require 'tex-mode) (require 'cl)
Mats> (require 'regexp-opt))
Mats> in texinfo.el.
Mats> I can't figure out from the documentation for
Mats> eval-when-compile how it is supposed to work, will
Mats> regexp-opt be loaded when a non compiled texinfo.el is
Mats> loaded or not?
No, it will not. The reason for the eval-when-compile is
that if you compile without loading regexp-opt first, there
will be unexpanded macro calls in the byte code, which will
fail (macros are supposed to be expanded before compiling).
However, you don't want to load unneeded cruft, so when
calling functions OR macros from texinfo uncompiled we depend
on autoload to make sure the library is loaded when needed.
Mats> However adding
Mats> '-l regexp-opt' (to the line in XEmacs.rules above)
Mats> makes building mew-ja.info work as expected.
Mats, does the package smoketest do an absolute build from the very
beginning? If not, you really should. Every time you build, do a `make
extraclean' (or even better, a fresh checkout). This will make it take
longer but you'll get more consistent results.
If you aren't currently doing this, nuke _pkg.el and auto-autoloads.* from
xemacs-packages/xemacs-base and rebuild. If you still get the problem, send
me the contents of _pkg.el and auto-autoloads.el.
10:31 p.m.
>>>> Ben wrote:
Ben> Mats, does the package smoketest do an absolute build from the
Ben> very beginning? If not, you really should. Every time you
Ben> build, do a `make extraclean'
Each build, for the different version of XEmacs, starts with a "make
distclean" to bring things back to a clean state. All package builds
are performed in the same package tree so the make distclean is
essential that it does its work well.
I can try "extra-clean" but all it seems to add is the removal of
backup files and that doesn't seem to be really what this problem is
all about.
Ben> (or even better, a fresh checkout). This will make it take
Ben> longer but you'll get more consistent results.
Yes but I'm trying to be smart here as well. The results from the "cvs
update" is used to find out if anything has changed since last
build. If not, the build is not performed.
You can also view it as a build problem if there isn't a target that
brings the package tree back into a clean state. :-)
Ben> If you aren't currently doing this, nuke _pkg.el and
Ben> auto-autoloads.* from xemacs-packages/xemacs-base and rebuild.
Ben> If you still get the problem, send me the contents of _pkg.el and
Ben> auto-autoloads.el.
If you still think extra-clean will do it I'll try it. (In fact I will
go ahead and try it immediately.) I'll remove _pkg.el and
auto-autoloads.* while I'm at it as well.
Yours
--
%% Mats
12:22 a.m.
Ben> If you aren't currently doing this, nuke _pkg.el and
Ben> auto-autoloads.* from xemacs-packages/xemacs-base and
rebuild. If
Ben> you still get the problem, send me the contents of _pkg.el and
Ben> auto-autoloads.el.
If you still think extra-clean will do it I'll try it. (In
fact I will go ahead and try it immediately.) I'll remove _pkg.el and
auto-autoloads.* while I'm at it as well.
No, that shouldn't matter. But could you send me _pkg.el and
auto-autoloads.el once they're generated?
7021
days inactive
7028
days old
4 comments
3 participants
participants (3)
-
Ben Wing -
Stephen J. Turnbull -
The XEmacs Package Smoketest