>>>> "dv" == Didier Verna
dv> Obviously, XEmacs took my package source directory for what it
dv> is not. After renaming it to XEmacs-Packages (note the
dv> uppercase) and reinstalling in order to update the symlinks,
dv> everything went fine again.
>>>> "ms" == Michael Sperber
ms> Ben yelled at me sufficiently to implement this. It's an
ms> intentional feature, and it only happens with an in-place
This, er, doesn't seem to be documented anywhere. info xemacs
'startup paths' says "If you run in-place, these [hierarchies] are
direct subdirectories of the build directory."
What is it that Ben wanted?
Is this just so that Windows users can put their installed package
hierarchy in c:\xemacs-packages and their sources in
c:\xemacs or something like that?
dv> To me, running in place would mean the ability to find the
dv> packages in my compiled cvs source tree withtout having to
dv> install them (whether by symlinks or not). But that's not that
dv> hey ?
ms> Yes, that's what it is. As opposed to a regular package
ms> hierarchy available to an in-place core.
Hm? I don't understand. It seems that you are saying that I should
be able to use a package source tree which is a neighbor of the build
directory as a package hierarchy. That's clearly not true; otherwise
there would be no need to rename your package source hierarchy. It
would just work.
I can think of several reasons why this is a bad idea, anyway.
(1) As implemented, it causes XEmacs to fail in a very non-transparent
way. This can be fixed as far as I'm concerned by testing
`(featurep 'xemacs-base)' or the equivalent, and reporting
(format "xemacs-base packages not found. Perhaps your\n"
"package hierarchies are weird? %s"
or something like that (`emacs-roots' probably doesn't give enough
information). But given (2), maybe it's preferable to revert this.
(2) In general, when working on packages you should probably be
testing with an installed XEmacs; when working on the core, you
should probably be testing against installed packages. If you
know what you're doing, and want to test development packages
against a development xemacs, it's easy enough to change this with
an environment variable, or by putting development packages in
your private hierarchy.
 Me, anyway. :-)
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."