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: tomas
Subject: Re: Add a configure option for NATIVE_FULL_AOT?
Date: Thu, 19 Aug 2021 09:27:06 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Aug 19, 2021 at 10:07:02AM +0300, Eli Zaretskii wrote:
> > 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.

Sometimes, questions just have to be put by somewhere else. Now
I understand your position better :-)

I agree that this problem hasn't a trivial (or unique) solution.
But this is something for distros to solve. Emacs has just to
provide the mechanisms to make that possible (and, as far as I
can see, it does).

Note that this problem already exists with .el/.elc files.

Cheers
 - t

Attachment: signature.asc
Description: Digital signature


reply via email to

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