On Tue, 2005-11-01 at 23:34 +0900, Stephen J. Turnbull wrote:
Pema> What's the point of with-package-prefix, if
~/.xemacs cannot
Pema> be specified with it?
Allowing you to keep multiple installed package trees around. This is
really of most interest to developers with large changes in their
packages who also need to test against the stable versions of
packages. Most users or administrators should simply figure out the
incantation for --with-package-path that corresponds to site policy
for installing third-party software, save it in a script, and not need
to worry ever again.
I used to use --package-path. Then --with-package-prefix was
implemented, which supposedly simplifies things (no need to specify
mule-packages etc.) - but ~/.xemacs is not in the path generated. Or has
that changed?
(2) the system package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages[1], under a single root
$package_prefix (by default /usr/local/lib/xemacs), and
Basically, this is the only path I want to change... But
--(with-)package-path requires all directories in search path to be
specified. That's what I'm using now, since --with-package-prefix does
not seem to work as I would like.
(3) personal package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages under a single root (pretty much
hard-coded to ~/.xemacs, although you can use --user-init-directory to
change it at run-time).
So there's actually little point to allowing the user to specify a
single location for early (ie, personal) packages.
That's true. But if I just use --with-package-prefix, ~/.xemacs is not
included in paths.
I only want to specify a single common package root (with
xemacs-packages, mule-packages & site-packages), and ~/.xemacs should be
added to path automatically. --with-package-prefix did not do this last
time I checked - maybe it has been changed.