emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add a configure option for NATIVE_FULL_AOT?


From: Eli Zaretskii
Subject: Re: Add a configure option for NATIVE_FULL_AOT?
Date: Thu, 19 Aug 2021 10:07:02 +0300

> From: Richard Stallman <rms@gnu.org>
> Cc: tsdh@gnu.org, emacs-devel@gnu.org
> Date: Wed, 18 Aug 2021 22:34:10 -0400
> 
>     That's not what I said or meant.  What I meant was that considering
>     the problem non-existent because this is how distros install the Lisp
>     files sounds strange to me, because it assumes no user will ever want
>     to modify these files enough to make them writable.  IOW, the
>     assumption that bothered me was that no one will ever want to modify
>     those files, e.g., to fix some bug or add a feature.
> 
> Distros must provide a way to download the sources.  You could
> download the sources into your home directory, make your modified
> versions, and put them in a directory in load-path.
> 
> Does this solve the problem, in practical terms?

Not the problem I was describing, it doesn't.

The problem I was describing was with the user modifying the *.el
files installed by a distro.  (The fact that distros by default
install *.el files in a place that is generally not writable by users
is irrelevant, because they can be made writable, or the *.el files
can be copied to a writable location and modified there.)  When users
do modify the *.el files, the corresponding distributed *.eln files
will no longer be loaded by Emacs, and there will be another version
of those *.eln files in a different location.  That is a gate to the
"DLL hell" in its Emacs incarnation: several different shared-library
objects of the same name in different locations.  At the very least,
users will be confused, and several obscure problems could happen that
will be hard to debug.  For example, the user's eln-cache directory,
where the updated *.eln files will be stored, could be cleaned up by
the user, not knowing that by doing that he/she effectively reverts to
using the old code, triggers JIT compilation when he/she loads the
same file the next time, etc.  Not a catastrophe, but certainly
confusing and not expected.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]