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

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>. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta