vc-hooks hosed, requires everything [Re: Pushing new vc towards regular packages tree]

[Ilya N. Golubev]

> it is expected that there are some rough 
> edges here and there.

One is that `vc-hooks' elisp library runs amok and requires each and
every vc backend, at least in some cases.

The whole point of `vc-hooks' always was to contain some minimum code
needed to recognize what other vc backends are needed, if any, and
thus to prevent requiring elisp libraries of all of these backends in
a lump.  It fails to serve this main purpose as follows.

Keep the following in `site-load-packages' (list) value in
`site-packages' in top xemacs build directory.

"../xemacs-packages/lisp/vc/vc-xemacs.elc"
"../xemacs-packages/lisp/vc/vc-hooks.elc"

(Having to load `vc-xemacs' is easily accountable for and not a
trouble in itself.)

Try to build xemacs.  It completes dumping normally, but `xemacs'
dumped this way is unusable, at least in the following invocation done
in course of normal build after dumping.

./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2 ${LISP}

(Using `${LISP}'.  Actually it is absolute name of `lisp' subdirectory
of top xemacs source directory.)

It exits with error, reporting the following lisp backtrace.

  signal(file-error ("Cannot open load file" "vc-rcs"))
  byte-code("..." [buf data kill-buffer signal] 3)
  find-file-noselect("${LISP}/custom-load.el" nil nil)
  # (unwind-protect ...)
  # bind (outbuf trim-name autoloads-done print-length print-readably float-output-format visited suppress-form output-end)
  byte-code()
  # (catch --cl-block-generate-autoload-type-section-- ...)
  # bind (fun-to-call literal load-name file)
  generate-autoload-type-section("${LISP}/custom-load.el" "custom-load" nil generate-lisp-file-autoloads-1)
  # bind (file)
  generate-file-autoloads("${LISP}/custom-load.el")

This way the build is broken.

In debugger could obtain richer backtrace.

  signal(file-error ("Cannot open load file" "vc-rcs"))
  # bind (path handler filename nosuffix nomessage noerror file)
  load("vc-rcs" nil require nil)
  # (unwind-protect ...)
  require(vc-rcs)
  # bind (f fun backend)
  vc-find-backend-function(RCS registered-lite)
  # bind (f args function-name backend)
  vc-call-backend(RCS registered-lite "${LISP}/custom-load.el")
  # bind (b)
  #<compiled-function (b) "...(34)" [file b fboundp vc-make-backend-sym registered vc-call-backend registered-lite vc-file-setprop vc-backend throw found t] 4>(RCS)
  mapcar(#<compiled-function (b) "...(34)" [file b fboundp vc-make-backend-sym registered vc-call-backend registered-lite vc-file-setprop vc-backend throw found t] 4> (RCS CVS SVN SCCS Arch MCVS GIT))
  # bind (backend)
  byte-code()
  # (catch found ...)
  # bind (handler file)
  vc-registered("${LISP}/custom-load.el")
  # bind (property file)
  vc-backend("${LISP}/custom-load.el")
  vc-find-file-hook()
  run-hooks(vc-find-file-hook)
  # bind (nomodes after-find-file-from-revert-buffer noauto warn error)
  after-find-file(nil t)
  # (unwind-protect ...)
  # bind (inhibit-read-only error number truename rawfile nowarn filename buf)
  find-file-noselect-1(#<buffer "custom-load.el"> "${LISP}/custom-load.el" nil nil "${LISP}/custom-load.el" (1825176 773))
  byte-code()
  # (condition-case ... . ((t (byte-code ))))
  # bind (number truename buf wildcards rawfile nowarn filename)
  find-file-noselect("${LISP}/custom-load.el" nil nil)

That is, `vc' sets xemacs up so that during the mere visiting of
arbitrary file that is possibly not under any version control at all
it requires this way not only `vc-rcs', but all other elisp libraries
for list in `vc-handled-backends'.  Did try to have this batch xemacs
load `vc-rcs', and confirming that this is not enough, it keeps
requiring more vc backend libraries exactly as they are listed in
`vc-handled-backends', until all of them are loaded.

Did observe that xemacs with the new vc loaded does not always behave
this way.  If dumped in xemacs (21.4 or 21.5) none of `vc' libraries,
and ran it interactively, it loaded only some reasonable fraction of
these libraries as files are visited.

Never tried to figure the exact conditions on which vc runs amok and
requires every backend library.  In particular, have no idea whether
xemacs has to be invoked in batch mode, or interactive uses are also
affected.

In any case, such a bulk loading of elisp libraries is intolerable
whenever happens.  So please put this bug in list of ones to be fixed
before what you committed on 2007/08/23 21:27:53 +0 leaves
<experimental area>.