9:44 p.m.
Hi,
* The problem
I get this error message when compiling the packages.
make[2]: Entering directory `/usr/local/src/packages/xemacs-packages/xslt-process'
xemacs -no-autoloads -batch -l /usr/local/src/packages/package-compile.el -- jde cc-mode
semantic debug speedbar edit-utils eterm mail-lib xemacs-base elib eieio sh-script
fsf-compat -- -f batch-byte-compile lisp/xslt-process.el
Loading /usr/local/lib/xemacs-21.5-b9/lisp/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/fsf-compat/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/sh-script/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/eieio/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/elib/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/xemacs-base/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/mail-lib/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/eterm/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/edit-utils/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/speedbar/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/debug/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/semantic/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/cc-mode/auto-autoloads...
Loading /usr/local/src/packages/xemacs-packages/jde/lisp/auto-autoloads...
Compiling /usr/local/src/packages/xemacs-packages/xslt-process/lisp/xslt-process.el...
Loading customization dependencies...
Loading customization dependencies...done
While compiling toplevel forms in file
/usr/local/src/packages/xemacs-packages/xslt-process/lisp/xslt-process.el:
!! File error (("Cannot open load file" "eldoc"))
[backtrace deleted]
* Brain starts working
Now, writing that got my brains working. It can't find eldoc.el so it
can't be included in the search path in the Makefile! (eldoc.el is
found in the xemacs-devel package)
Here is the patch.
"cvs diff -u" in /usr/local/src/packages/xemacs-packages/xslt-process/
Index: Makefile
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/xslt-process/Makefile,v
retrieving revision 1.24
diff -u -u -r1.24 Makefile
--- Makefile 2002/07/14 05:41:46 1.24
+++ Makefile 2002/10/07 20:37:26
＠＠ -25,7 +25,7 ＠＠
PACKAGE = xslt-process
PKG_TYPE = regular
REQUIRES = jde cc-mode semantic debug speedbar edit-utils eterm \
- mail-lib xemacs-base elib eieio sh-script fsf-compat
+ mail-lib xemacs-base elib eieio sh-script fsf-compat xemacs-devel
CATEGORY = standard
MAKE ?= make
* Related.
If I'm not entirely mistaken this error has been there for a while and
the reason it hasn't been notices, I'm guessing here of course, must
be that nobody rebuilds the packages (from scratch!?)
regularly. Wouldn't it pay of if there was a daily build of the
packages so that these types of small problems was spotted earlier?
Yours
--
%% Mats
10:23 p.m.
New subject: [AC] Re: Problems compiling ...xslt-process.el. Patch included.
APPROVE COMMIT
On Mon, 2002-10-07 at 23:44, Mats Lidell wrote:
Now, writing that got my brains working. It can't find eldoc.el
so it
can't be included in the search path in the Makefile! (eldoc.el is
found in the xemacs-devel package)
And it gets even weirder when you "grep -rn 'eldoc' *" in the
xslt-process package dir: no hits :)
If I'm not entirely mistaken this error has been there for a
while and
the reason it hasn't been notices, I'm guessing here of course, must
be that nobody rebuilds the packages (from scratch!?)
regularly. Wouldn't it pay of if there was a daily build of the
packages so that these types of small problems was spotted earlier?
This is a known problem in the package system, I'm sure there are people
building the packages often enough. The problem is that recursive
requirements are not handled properly, and one won't get bitten by it
unless compiling in *a* package dir (in this case,
xemacs-packages/xslt-process). Compiling in packages/ or
packages/xemacs-packages/ would work, which is what most people seem to
do.
But adding these indirect requirements into packages whenever we find
them is the best we can do for now, so I've applied the patch.
Oh, and eldoc seems to be required by xslt-process indirectly via jde
and/or semantic.
Thanks,
--
\/ille Skyttä
ville.skytta at xemacs.org
11:30 p.m.
New subject: [AC] Re: Problems compiling ...xslt-process.el. Patch included.
>>>> Ville wrote:
Ville> This is a known problem in the package system, I'm sure there
Ville> are people building the packages often enough.
If that is the case how come these error are there so long!?
Ville> The problem is that recursive requirements are not handled
Ville> properly, and one won't get bitten by it unless compiling in
Ville> *a* package dir (in this case, xemacs-packages/xslt-process).
Ville> Compiling in packages/ or packages/xemacs-packages/ would work,
Ville> which is what most people seem to do.
This is what I do too all the time and still I got the error.
Ville> But adding these indirect requirements into packages whenever
Ville> we find them is the best we can do for now, so I've applied the
Ville> patch.
Agreed. The fix is the same.
Ville> Oh, and eldoc seems to be required by xslt-process indirectly via jde
Ville> and/or semantic.
My point is that if you don't tell make the whole story through the
dependencies you have to fall back to the procedure to rebuild
everything. A daily build could do that and thus faster point out if
there are inconsistencies in the build process.
Yours
--
%% Mats
2:57 a.m.
New subject: [AC] Re: Problems compiling ...xslt-process.el. Patch included.
>>>> Ville wrote:
Ville> This is a known problem in the package system, I'm sure
Ville> there are people building the packages often enough.
>>>> "Mats" == Mats Lidell
<matsl(a)contactor.se> writes:
Mats> If that is the case how come these error are there so long!?
Because the package system is rife with them. Remember, the packages
were simply carved as a piece out of the main tree. They (and Lisp in
general) are very mutually recursive; they're not designed for
separate building. We're slowly getting to the point where building
only a couple of packages is likely to work, but I doubt this is the
last "can't build packages except from the top of the tree" bug we'll
run into. And because of the mutual recursions, I doubt we'll ever
see the day where it makes sense to build outside of a full package
source tree for every package. Of course there will always be
standalone packages, and hopefully we'll see the day where a binary
tree can stand in as a source tree, but we're not there yet.
The latter is the right fix, but that will require changes to core
(it's the expectation in core that binary Lisp packages are found in
lisp/$package rather than $package/lisp that should be changed).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:58 a.m.
New subject: [AC] Re: Problems compiling ...xslt-process.el. Patch included.
>>>> Stephen wrote:
Stephen> We're slowly getting to the point where building only a
Stephen> couple of packages is likely to work, but I doubt this is the
Stephen> last "can't build packages except from the top of the tree"
Stephen> bug we'll run into.
I'm afraid I don't understand. This was an error I got when I built
from the top. I always do. I don't always do a make distclean first
but this time I did and I suppose I always should to be on the safe
side.
What I'm suggesting is that we should have a daily build that builds
from the top (make distclean; cvs update -dP; make) that hopefully
will spot these problems early.
Yours
--
%% Mats
3:54 p.m.
New subject: [AC] Re: Problems compiling ...xslt-process.el. Patch included.
On Tue, 2002-10-08 at 12:58, Mats Lidell wrote:
What I'm suggesting is that we should have a daily build that
builds
from the top (make distclean; cvs update -dP; make) that hopefully
will spot these problems early.
Sounds like a good idea to me. I'll take a look at making my home box
to do this, sending build errors to xemacs-beta (?).
--
\/ille Skyttä
ville.skytta at xemacs.org
8081
days inactive
8082
days old
5 comments
3 participants
participants (3)
-
Mats Lidell -
Stephen J. Turnbull -
Ville Skyttä