[EMAIL PROTECTED] writes:
> On 4282 September 1993, J. wrote:
>> I think this requires some changes in the policy:
>> Common .el files could be installed in /usr{,/local}/share/emacsen/site-lisp
>> which is not a standard location in Emacsen's path.
>> It would replace /usr/{,/local}/share/emacs/site-lisp in both Emacsen
>> paths and the problem would vanish.
>
> As elaborated elsewhere in this thread, I think that such a change
> requires an appropriate message when upgrading XEmacs.
>
>> Any other idea?
>
> No, but please note that it's in some respect only a partial solution,
> as it doesn't fix the two problems of possible load-path shadows (but
> that's okay, IMHO, it's not really solvable)
Well, I wanted to list the load-path in order to illustrate the
problems that can occur if some packages come with compiled Elisp
files, and a package supposed to be earlier in the load order comes
just with source. Unfortunately, my stock XEmacs right now is
completely broken:
[EMAIL PROTECTED]:~$ xemacs -q -no-site-file
WARNING:
Couldn't find obvious defaults for:
data-directory
mule-lisp-directory
lisp-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/bin/xemacs
is in a strange place?Warning: Missing charsets in String to FontSet conversion
Anyway: neither Emacs nor XEmacs are designed to separate .el and .elc
files into separate directories. Commands like list-load-path-shadows
get confused by it, commands like byte-recompile-directory don't work
properly, warnings like "Source file is newer than compiled file"
don't work at all, and in the case of multiply defined files, the
search path manipulations mean that shadowings act weird and
differently when I am using compiled and non-compiled files.
.el and .elc files belong in the same directory, by _design_ of both
Emacs and XEmacs. Whether they should get there by copying or hard
linking or symlinking is a different question.
load-path manipulations don't work for this purpose, however. They
render the Emacs/XEmacs infrastructure non-operative.
> and of binary incompatibilites. I.e., if the user tries to
> byte-compile any files in $PREFIX/emacsen/* it's likely that he ends
> up with *elc that just work under one version of Emacs.
That's why this directory should not be in the load-path in the first
place.
> The policy should thus contain a note that files under emacsen
> should not be byte-compiled. The only clean way around this is to
> move any byte-compiled file to a version-specific directory.
Not just the compiled files, but the source files as well.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
