>>>> "Stephen" == Stephen J Turnbull
>>>> "Michael Sperber [Mr. Preprocessor]"
>> many environments and ways I never envisioned. It certainly
>> was part of my intention that, if you run in-place, you run
Stephen> 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.
Stephen> I think as described here it's bad design, too. The packages are
Stephen> intended to be a separate module from the core. Running core in-place
Stephen> should find the core lisp under core, but the packages must be located
Stephen> by other criteria. Note that packages _cannot_ run in-place, they
Stephen> must be installed. Installing packages into an in-place core seems
Stephen> more than a bit weird to me.
Stephen> I've been bitten many times by having symlinks to the packages in my
Stephen> core directory, I don't want that. And that is just installing-by-
Stephen> alias, anyway.
Stephen> It also seems inconsistent with features like the --package-path
Stephen> configure flag and the EMACSPACKAGEPATH environment variable.
Stephen> Finally, I have very little time to work on the packages. Nor do I
Stephen> want to have non-canonical packages (ie with local mods) in the
Stephen> environment where I test XEmacs 21.4. I imagine there are a lot of
Stephen> testers who feel the same way, they use the packages as is but they
Stephen> like to try the latest and greatest core code. This is an important
Stephen> specification for in-place XEmacs, IMHO. If an in-place XEmacs does
Stephen> not normally find my installed packages, then as far as I'm concerned,
Stephen> it doesn't "just work", I may as well install it.
before you make sweeping judgements like this, it would be nice if you
could calm down and review the issue at hand ...
... which is whether a vanilla-configured XEmacs *without* any special
indication where the packages should snarf them under /usr/local.
There is no correct answer to this question, as we've had bug reports
from environments where this is precisely the *wrong* thing to do.
If you want to pick up an installed package hierarchy that doesn't
live in a fully populated XEmacs root hierarchy (which is what Michael
is trying to do), I think it's it's entirely reasonable to expect an
explicit hint on where the packages are, that is, either via the
--package-path configure option or via the EMACSPACKAGEPATH
The reason why the scenario Michael describes used to work and doesn't
work now is that XEmacs used to diagnose the "XEmacs root hierarchy"
property of a directory via a different criterion. In Michael's case,
it did so *wrongly* because there wasn't an XEmacs root hierarchy
there, just the packages. The criterion changed at your (Stephen's,
that is) suggestion, and justly so.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla