Re: [AC21.5] commit: Add support for installing bundled packages.

Deleting xemacs-patches, I consider this discussion to pertain to a follow-on patch. Michael Sperber writes: OK, thanks; I do need to check that it's not a path; at least at the start I want to cater to the configuration that the user only configures late (aka "system") packages to *one* directory, defaulting early packages (to ~/.xemacs, IIRC) and last packages (to nothing). People who want to do something more complicated are on their own---they know what they want to do and why, and I don't. This feature is purely and simply about getting XEmacs up and running for those who don't need to know, and it's rude to force them. Hm, I should fix those messages to say *where* the packages will be installed. OK, this little thing is done. Deciding what to do about defaults (should they count as configured? -- I think so) and what to do about non-trivial paths (take the first one -- I think not) needs to be done, though. I'm not sure I understand your question. I've always advocated that XEmacs should have two (sets of) installation roots: one for the core and one for the packages. I would say that all configured hierarchies should be considered package roots regardless of whether xemacs is running in-place or not. If you want a pure instance that only finds its own lisp and its own set of packages, configure --with-prefix=no and --with-user-packages="", and xemacs should look for packages only in src/../{xemacs,mule,site}-packages and its own Lisp in ../lisp. I'm aware of the arguments for the alternative, considering that the VM (bytecode interpreter) is an internal detail, and compiling everything for the current interpreter. However that is not the way we have worked in practice. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta