>>>> "Michael Sperber [Mr. Preprocessor]"
<sperber(a)informatik.uni-tuebingen.de>
> many environments and ways I never envisioned. It certainly
> was part of my intention that, if you run in-place, you run
This is news to me. :-(
> *everything* in-place, and I feel qualified to say that your
> being able to run in this split setup is mere accident.
I think as described here it's bad design, too. The packages are
intended to be a separate module from the core. Running core in-place
should find the core lisp under core, but the packages must be located
by other criteria. Note that packages _cannot_ run in-place, they
must be installed. Installing packages into an in-place core seems
more than a bit weird to me.
I've been bitten many times by having symlinks to the packages in my
core directory, I don't want that. And that is just installing-by-
alias, anyway.
It also seems inconsistent with features like the --package-path
configure flag and the EMACSPACKAGEPATH environment variable.
Finally, I have very little time to work on the packages. Nor do I
want to have non-canonical packages (ie with local mods) in the
environment where I test XEmacs 21.4. I imagine there are a lot of
testers who feel the same way, they use the packages as is but they
like to try the latest and greatest core code. This is an important
specification for in-place XEmacs, IMHO. If an in-place XEmacs does
not normally find my installed packages, then as far as I'm concerned,
it doesn't "just work", I may as well install it.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.