emacs-devel
[Top][All Lists]
Advanced

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

Re: Suppressing native compilation (short and long term)


From: Michael Welsh Duggan
Subject: Re: Suppressing native compilation (short and long term)
Date: Sat, 08 Oct 2022 13:47:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

In an effort to try and bridge the understanding gap, I'm going to
contribute my current understanding of Debian's requirements, in the
hopes that we might be able to identify any misunderstandings.
Apologies in advance if this just retreads old ground and doesn't add
anything useful to the conversation.

>From Debian's point of view, there are a few scenarios under which emacs
is run:

1) When building emacs (used as part of emacs bootstrap) 
2) When installing emacs via dpkg (maybe?  Not certain)
3) When building an emacs package (maybe?  Not certain)
4) When installing an emacs package via dpkg
5) When a user runs emacs

Here are the constraints that I have intuited from the conversation:

a) Case 1 builds .eln files, which will be packaged and installed in
   case 2.

b) Cases 1 and 3 normally happen on a Debian build machine.  These do
   *not* want emacs to write anything to $HOME, though writing to a
   temporary location that will subsequently be thrown away is okay.

c) Case 3 might not require running emacs at all, but I can imagine that
   emacs might be run as part of the build process to auto-generate some
   files.

d) Cases 2, 4, and 5 occur on a Debian user's machine.

e) Cases 2 and 4 are run under root (or similar) and should not write to
   $HOME.

f) Case 2 will install the .eln files packaged in case 1 into a
   world-readable, read-only location.  An Emacs run in case 5 will
   include that location in its native file search path.

g) Case 4 might run emacs to build .elc and .eln files for the package's
   .el files and place them in world-readable, read-only locations.  An
   Emacs run in case 5 will include that location in its native file
   search path.

h) Case 5 should read .eln files from the world-readable, read-only
   locations mentioned above, when possible, but otherwise should do
   native compilation and store the generated .eln files in the standard
   user locations based on $HOME.

Open questions:

i  ) In case 2, are the emacs binaries and the elisp files in the same
     package, or are they split into different packages?  If the latter,
     which package should contain the .eln files?

ii ) Do we want (g) to actually happen?  If so, do we want it to happen
     always, or should this be configurable in the emacs package
     (dpkg-configure)?

iii) Does case 2 also delete files created in (g) and re-generate them
     using the newly installed Emacs?

-- 
Michael Welsh Duggan
(md5i@md5i.com)



reply via email to

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