() Stephen Leake <[EMAIL PROTECTED]>
() Fri, 01 Aug 2008 04:15:36 -0400
make -r
cd lisp; make
make[1]: Entering directory `/Gnu/dvc/lisp'
srcdir=. otherdirs="" emacs -batch -q --no-site-file -l ./dvc-build.el -f
dvc-build-autoloads .
Merging cus-load.el into dvc-autoloads.el (c:\Gnu\dvc\lisp/)...
Opening input file: no such file or directory, c:/Gnu/dvc/lisp/cus-load.el
cus-load.el is generated by the build process, but then it is deleted.
Here are the relevant messages from the build process:
Generating cus-load.el...
Wrote c:/Gnu/dvc/lisp/cus-load.el
Generating cus-load.el...done
...
Merging cus-load.el into dvc-autoloads.el (c:/Gnu/dvc/lisp/)...
In dvc-build.el, dvc-build-autoloads does:
(message "Merging %s into %s (%s)..."
(file-name-nondirectory --custom-autoloads-filename)
(file-name-nondirectory --autoloads-filename)
default-directory)
(with-temp-file --autoloads-filename
(insert-file-contents --custom-autoloads-filename)
(delete-file --custom-autoloads-filename)
I've commented out the 'delete-file' for now.
Hmm, that fragment is evaluated after `custom-make-dependencies' (which
is the function that writes cus-load.el) is called, so in theory
cus-load.el should exist in the current directory. Perhaps some defunct
.el{c} files still lying might be confusing `missing-or-old-elc'. Can
you reproduce the problem with a clean checkout or after a "make clean"
(and with the `otherdirs' patch applied)?
Why is cus-load.el merged into dvc-autoloads.el, instead of left as a
separate file?
I don't know -- that's what the code has always done since i started
looking at it (there might be an answer given a little digging in the
history).
Why does it have a different name under XEmacs?
No idea.
That implies Emacs expects to find that file, which says we should
not be deleting it.
Not really: the merging is wrapped in `(unless (featurep 'xemacs) ...)'.
Now when I run 'make', it always regenerates the autoloads. I guess
that's why cus-loads is deleted, but something needs to change.
I've done semantics-preserving transformations only (i hope). Maybe
i'll take a crack at rationalizing and redesigning autoloads building.
thi
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
