Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> Summary of changes:
> <snip>
>
> I'll wait a few days before starting on -config-2, which depends on what
> people think of deleting dvc-site.el. Notable for DVC hackers will be the
> blurb in docs/HACKING (Programs for maintainers).
This gives me some build errors:
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 .
Env var `otherdirs' not set
Since the default is for 'otherdirs' to be empty, this can be fixed by
patching dvc-build.el:
(defvar otherdirs (or (getenv "otherdirs")
""))
That lets the first build complete. But then if I rerun 'make' (just
to be sure), I get:
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.
Why is cus-load.el merged into dvc-autoloads.el, instead of left as a
separate file?
Why does it have a different name under XEmacs? That implies Emacs
expects to find that file, which says we should not be deleting it.
Now when I run 'make', it always regenerates the autoloads. I guess
that's why cus-loads is deleted, but something needs to change.
Otherwise, this build process does look much cleaner.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
