() Stephen Leake <[EMAIL PROTECTED]> () Sat, 02 Aug 2008 08:22:51 -0400
So custom-make-dependencies is not run in this case.
OK.
> [ttn in-the-dark guess]
Yes, same problem after clean checkout, autoreconf, configure, make,
make.
OK.
missing-or-old-elc returns ("dvc-autoloads.el") in this case.
[Aside: which I discovered by convincing dvc-build.el to let me run
interactively. It's really a pain trying to debug this stuff!]
Yeah, i know how you feel. On the one hand, interactivity introduces
personal environment (~/.emacs et al) problems, so you want to enforce
non-interactive operation/testing, but on the other hand, visibility for
non-interactive debugging is really poor. Here's a small function that
you might find useful when forced to do "printf-debugging":
(defun pk (&rest args)
(apply 'message (car args) (cdr args))
(car (last args)))
This is styled after Guile's `pk' and supported by pk-unpk.el (attached).
That's because --autoloads-filename is absolute
"c:/Gnu/dvc/lisp/dvc-autoloads.el", but in the computation of
--to-compile, it is in the "plus" branch as "dvc-autoloads.el".
Good catch! Since dvc-autoloads.el is written in `default-directory',
anyway, the `expand-file-name' is indeed superfluous. The bug was
introduced in "Consolidate build functionality into dvc-build.el" when
moving to the functional style `--to-compile' init from the imperative
style `package-maint-files' (and `no-compile-files') init. Drat. I
guess i didn't "follow the simple rules" enough. :-/
Changing the initialization of --autoloads-filename to:
(defvar --autoloads-filename (if (featurep 'xemacs)
"auto-autoloads.el"
"dvc-autoloads.el"))
lets successive 'make' succeed: [...]
Cool. I will remove the `expand-file-name'.
Thanks for diagnosing both problems and providing the fixes.
thi
______________________________________
pk-unpk.el
Description: application/emacs-lisp
_______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
