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

Stephen J. Turnbull turnbull at sk.tsukuba.ac.jp
Wed Dec 26 14:42:19 EST 2007


Deleting xemacs-patches, I consider this discussion to pertain to a
follow-on patch.

Michael Sperber writes:

 > Path.

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.

 > > To configure the package path, use the --with-late-packages option to
 > > configure, which specifies the path to the directory containing the
 > > xemacs-packages and mule-packages hierarchies to install.
 > 
 > Should we find these automatically for in-place operation?

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.



More information about the XEmacs-Beta mailing list