Symbol’s value as variable is void: auto-save-list-file-prefix
HnimNart opened this issue · comments
Hi
First of all, thank you for your work.
After installing emacs 28.1 on Ubuntu 22.04 LTS I get an error when trying to open emacs.
$ emacs -Q
Symbol’s value as variable is void: auto-save-list-file-prefix
emacs --debug-init gives same error.
Do you know what is causing this?
Same here, with Ubuntu Mate 22.04 and installing Emacs 28 from the ppa. I could start Emacs in the terminal with Emacs -nw, but it refused to start in gui. When starting in terminal mode it didn't want to load any configuration, so it was basically useless even if the install wasn't completely broken.
Hm, interesting. My Google-fu turns up some results that suggest that this might be related to the native compilation feature.
I'll take a look as soon as I have time; if anyone else does any investigating, please share anything that you find with us!
[Edit:] This is also happening with an install on a relatively vanilla 20.04 LTS machine.
I get the same bug as the other commentators
drewverlee@drewverlee ~ emacs
Symbol’s value as variable is void: auto-save-list-file-prefix
✘ drewverlee@drewverlee ~ which emacs
/usr/bin/emacs
drewverlee@drewverlee ~ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
I observe the same problem with WSL 2 with ubuntu 20.04.4 LTS.
Has anyone tried with the 18.04 LTS ("bionic") packages? They were built without native compilation, so they might help to confirm that it's the issue.
Unless anyone has any thoughts about troubleshooting the problem itself, I'm going to try to make some time today or tomorrow to push packages that disable it in the interim.
I've uploaded source packages (version emacs28_28.1~1.git5a223c7f2e-kk2) that disable native compilation. In my local testing, they do not have this issue. Please give them a try once they're available on Launchpad.
We still need to investigate and see if we can figure out how to enable the feature without causing trouble. Let me know if you have any thoughts!
@kelleyk FYI, Archlinux provides two packages for emacs 28. One package without native compilation (emacs package) and emacs-nativecomp with native compilation. Would having both versions be a problem?
I've just reinstalled emacs28 from Launchpad, and it's now working great: the error message is gone. Thank you!
@dmusican Awesome; sorry for the trouble, and thank you for confirming that the fix worked for you.
@innerout We could absolutely look into doing that if there were a good reason for it. In general, my philosophy has been to enable everything; are there drawbacks to having native compilation enabled (assuming that we get this issue straightened out)? Are there people who would prefer the emacs package over the emacs-nativecomp package?
[Edit:] I'm assuming that everybody got this error from the -kk1 packages. If that isn't true, please let me know.
First of all, I want to mention that I am a native comp user; however, there are some cases where users may opt-out of it.
- Their computer may not have enough resources for Emacs native compilation and the task they are trying to do.
(e.g., compiling a doom emacs configuration is a heavy task) - Their configuration is fast enough, and there would be no benefit from the native compilation.
- Their computer may not have enough resources for Emacs native compilation and the task they are trying to do.
(e.g., compiling a doom emacs configuration is a heavy task)
Wouldn't native comp be a compelling feature for someone with a weak computer, rather than a bad feature? Sure the compilation is heavy, but that should only done once, right? Once the compilation is done, I feel like the benefits will be noticable especially on weak computers. Or am I missing something regarding native comp? I can admit that I have never used it so far.
- Their configuration is fast enough, and there would be no benefit from the native compilation.
I think I would say that this is true for me. The only bottleneck I sometimes feel is a slow LSP server, and perhaps worth noting is that the praised native json parser haven't helped the slightest. But even if my config is fast enough, I don't mind it being faster. Emacs being faster also gives me more freedom in writing potentially compute heavy custom functionality.
I'll say I don't mind there being 2 version of Emacs in the ppa. But at least I'm not convinced of the value, especially considering that kelleyk might not have infinite time or resources to put into the ppa. I'm just happy that there is a ppa, native comp or not.
I understand that kelleyk may not have the time or the resources. I am just giving an example if this is possible, and it is not a significant overhead for kelleyk. At least having two packages until a permanent solution is found would be great to avoid breakages.
Are there people who would prefer the emacs package over the emacs-nativecomp package?
I don't know. I've been experimenting with native comp in the last day or two (via the snap release), and I'll admit, the build time is cumbersome.
Sure the compilation is heavy, but that should only done once, right?
I use Doom Emacs, which means that every time I do an doom upgrade, many packages come down with updates, and then they get recompiled. It makes updating dramatically slower. How often does one update? It depends on the individual. I typically do a doom upgrade when I stumble on something that might be broken; perhaps I do it once every few weeks. Without native comp it takes a few minutes to do a doom upgrade, as it downloads a whole lot of new packages. With native comp... I haven't timed it carefully, but it's dramatically longer.
But back to the original question --- does that mean I'd go without native comp? I don't know. I need more time to live with it and see how it goes. And I'll echo comments from others: I'm just grateful that kelleyk can provide a PPA of any sort. Asking for two might be unreasonable.
I would add that nativecomp should be compiled by default. I'm still not familiar with it, but I guess all nativecomp functionality has their respective toggles which would avoid breakages in case issues arise and would help also those wanting to opt-out of it. However, mine has no nativecomp 😢 so I didn't test it.
As said before, having two packages with and without nativecomp seems overkill and adds unwanted extra burden, which should be avoided due to scarcity of maintainer's bandwidth, at least until everything is more automated.
Leaving out nativecomp would be sad, specially since is one of the greatest changes in Emacs 28.1 (actually, the first one in the NEWS file).
It might make sense to bring this up in emacs-devel - the author of native compile feature is pretty responsive in there.
First, thanks for maintaining this PPA, which has long been my preferred Emacs source for Ubuntu.
[Edit:] I'm assuming that everybody got this error from the
-kk1packages. If that isn't true, please let me know.
I've been using Emacs 28.1 built with native compilation enabled on Ubuntu 22.04 for a few weeks, and am not affected by this variable is void: auto-save-list-file-prefix error. Built from upstream emacs-28.1.tar.xz, with GCC 11 and libgccjit-11-dev, without Xwidgets support (which is broken on my system: causes graphical glitches and other UI bugs when displaying the browser window).
This week-end I was trying to rebuild Emacs with a configuration as close as possible to the one used by this PPA, and assumed the system-configuration-options value reported in #26 , plus --with-native-compilation:
$ ./configure --prefix=$HOME/.local --with-native-compilation --with-modules --with-file-notification=inotify --with-mailutils --with-harfbuzz --with-json --with-x=yes --with-x-toolkit=gtk3 --with-lcms2 --with-cairo --with-xpm=yes --with-gif=yes --with-gnutls=yes --with-jpeg=yes --with-png=yes --with-tiff=yes --with-xwidgets "CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -no-pie" "CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2" "LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -no-pie"
$ make -j8
$ make install
I still couldn't reproduce the error (I've tried emacs -q, emacs -Q, emacs -nw, emacs -Q <some file>, as well as loading my full configuration).
I've also built the sources at master-emacs28.1-jammy, with the same build settings, which worked fine:
$ git clone git clone https://github.com/kelleyk/ppa-emacs.git
$ cd ppa-emacs
$ git checkout master-emacs28.1-jammy
$ ./autogen.sh
$ ./configure --prefix=$HOME/.local --with-native-compilation --with-modules --with-file-notification=inotify --with-mailutils --with-harfbuzz --with-json --with-x=yes --with-x-toolkit=gtk3 --with-lcms2 --with-cairo --with-xpm=yes --with-gif=yes --with-gnutls=yes --with-jpeg=yes --with-png=yes --with-tiff=yes --with-xwidgets "CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -no-pie" "CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2" "LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -no-pie"
$ make -j8
$ make install
AFAICT, the variable auto-save-list-file-prefix is early initialized to ~/.emacs.d/auto-save-list/.saves- by startup.el:
(defcustom auto-save-list-file-prefix
(cond ((eq system-type 'ms-dos)
;; MS-DOS cannot have initial dot, and allows only 8.3 names
(concat user-emacs-directory "auto-save.list/_s"))
(t
(concat user-emacs-directory "auto-save-list/.saves-")))
How this could silently fail is far beyond my understanding of Emacs' internals.
[Edit: fixed typo where startup.el was written setup.el.
In case someone is looking for this file: Emacs installs only the compiled version at prefix/share/emacs/28.1/lisp/startup.elc, but will gently decompile it on-the-fly. If searching the Emacs source tree, these Lisp files are in the lisp directory, not src.]
But my feeling is that native lisp compilation does not per se trigger the error, at least not on all platforms, and we may not take for granted it alone being the culprit: enabling native compilation may as well permit to an otherwise harmless (configuration) issue to show itself (guesswork).
For completeness, note that a difference remains between our builds, which may or not be relevant: I always build with a user owned prefix (here --prefix=$HOME/.local), where this PPA (obviously) builds a package for system wide installation.
I'm sorry I couldn't test the exact package at fault (28.1~1.git5a223c7f2e-kk1), my weak APT-fu failed to install both its binary and source (I can reach only the latest version):
$ sudo apt list -a emacs28
Listing... Done
emacs28/jammy 28.1~1.git5a223c7f2e-kk2+22.04 amd64
sudo apt install emacs28=28.1~1.git5a223c7f2e-kk1+22.04
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package emacs28 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
emacs28-nox
E: Version '28.1~1.git5a223c7f2e-kk1+22.04' for 'emacs28' was not found
$ sudo apt source emacs28=28.1~1.git5a223c7f2e-kk1+22.04
Reading package lists... Done
E: Can not find version '28.1~1.git5a223c7f2e-kk1+22.04' of package 'emacs28'
E: Unable to find a source package for emacs28
I'm willing to help finding a better solution than fully disabling native compilation, which I can confirm is worth performance wise (at the cost of the initial lisp packages compilation, which some peoples may feel uncomfortable with): you can submit me any additional test you would think useful.
For e.g. you could provide me with:
- a pointer to the
-kk1sources I've been too dumb to find myself - your value for
system-configuration-optionsif our build settings differ more than I've assumed
Thanks.
--
chris
Thank you for digging in and helping with this!
I should sit down and see what happens if I build Emacs outside of the packaging as well---if I can reproduce your results, that would point at there being something about the packaging (outside of the build configuration) that needs to be tweaked.
Just some quick thoughts before I have a moment to sit down and really spend more time on this:
Re: finding source packages, do you have deb-src lines in your apt sources for the PPA? The sources are on the master-emacs28.1-jammy branch; the current HEAD of that branch has the sources for the -kk1 packages (since the -kk2 packages were built from a different branch).
The build configuration is in debian/rules.
More soon!
Just to add an extra opinion: I personally think any Emacs 28 OS package which users might upgrade to in some semi-automated fashion should definitely be built without native compilation, and that regardless there should be separate packages (with and without native compilation) if this feature is provided at all. This way users who wish to try native compilation can opt in, but it's not forced on anyone; and if they try it and don't like it, they can opt-out again.
There are many potential downsides to native compilation. I know of one user whose hardware was so low-spec that native compilation was going to take all day long (and was making the machine completely unusable while it was happening), whereas non-native Emacs was usable for them (and always had been). One could argue in favour of waiting that out for an ultimate benefit, but that shouldn't be the default. Even on high-spec hardware, compilation tends to be pretty noticeable, and users who update elisp packages regularly are going to be affected by that a great deal. Consider also that some users will be entirely unaware of the feature when they upgrade, and therefore may be rather alarmed when all that initial compilation unexpectedly kicks in and eats most of their CPU resources.
Native compilation has also been observed to interact badly with some virus scanners, potentially slowing start times by an order of magnitude (in return for which the actual benefits of native compilation are unnoticeable to some users).
In other words, the effects (and/or perceived effects) of native-compilation vary wildly, and one size does not fit all, so forcing it on users seems like a mistake to me.
(That said, I fully respect that the maintainer may not have time to maintain more than one package, and that users have other options for installing Emacs if this one isn't suitable for them for any reason.)
This week-end I was trying to rebuild Emacs with a configuration as close as possible to the one used by this PPA, and assumed the
system-configuration-optionsvalue reported in #26 , plus--with-native-compilation:
Seems like that's related to #22 - having exact build procedure at hands would help with reproducing the issue.
Question for @kelleyk: would it be hard to provide two packages, one with native compilation and one without? Because I think I got the first version (with native compilation) working for me before you updated it.
And I also got it working when compiled from sources for some time now.
Perhaps having the two versions (at least temporarily) would help us debug the issue, without everyone having to rebuild the packages ourselves.
if I can reproduce your results, that would point at there being something about the packaging (outside of the build configuration) that needs to be tweaked.
I agree there might be some packaging issue, since it seems I'm not the only one to daily run Emacs28 with native compilation on a debian/Ubuntu based system (at least @rcoacci does). And I'm not aware of any wide spread noise about Emacs native compilation being broken (if we ignore the NATIVE_FULL_AOT thing).
IMHO, this variable is void: auto-save-list-file-prefix error just sounds like a legit Lisp error caused by an uninitialized variable being referenced (but we don't know from where, even peoples that tried --debug-init couldn't come with anything like a call stack trace).
At least it's still my working (slowly, on spare time) hypothesis: I'm digging for different Emacs startup Lisp code paths depending on whether native compilation is enabled or not (Lisp predicate native-compile): and there are some.
But I would so much prefer being able to reproduce the error: without this I'm mostly going guesswork, I regret.
Re: finding source packages, do you have
deb-srclines in your apt sources for the PPA?
Yes, I have the appropriate deb-src line in my /etc/apt/sources.list.d/kelleyk-ubuntu-emacs-jammy.list.
But my APT-fu fail to find anything besides the -kk2 packages (both source and binary).
The sources are on the
master-emacs28.1-jammybranch; the current HEAD of that branch has the sources for the-kk1packages (since the-kk2packages were built from a different branch).
I think I've already tested these with:
$ git clone https://github.com/kelleyk/ppa-emacs.git
$ cd ppa-emacs
$ git checkout master-emacs28.1-jammy
et cetera
The build configuration is in
debian/rules.
Thanks for the debian/ hint.
For sanity I've tested a build with the debian patch (debian/patches/kk-xinput-bugfix) applied, but unsurprisingly that didn't help triggering the error.
I've parsed these debian/rules, nothing eye-catching, but as you've probably noticed, I'm actually not comfortable with debian packaging (I primarily run Red Hat type Linuxes):
- from the
master-emacs28.1-jammysource tree I've cloned, can I simply run the debian build procedure, for e.g. is there amaketarget I've missed ? - or should I preferably grab the
-kk1debian source package, how ? - to build ala debian, I will probably need specific tools like
dpkg-buildpackageand a minimum background regarding the underlying process, but I don't even know if there are differences between debian and Ubuntu in this area: it'd be great if you had a good pointer at hand, something that could teach me what I need without too much overhead
@zabbal
Agreed, a README about the build procedure could probably prove helpful, and anyone should be able to (re-)build the exact debian package that APT would install.
But I'm afraid that we (me for sure) also lack some knowledge regarding the debian/Ubuntu build and packaging procedures, knowledge that is easily available online. But time consuming, as any knowledge.
To @phil-s , @pataquets , and more generally regarding whether to enable or not native compilation, or to have one or two Emacs28 packages.
To me all sides of the coin are valid:
- native compilation (once done) is definitely a win performance wise, and it'd be sad to not offer it broadly
- the pain reported by peoples with lower end hardware is also definitely not negligible; and even peoples with higher end machines may feel uncomfortable with the occasional UI latency caused by initial packages compilation
- maintaining two distinct packages would obviously add some burden on the actual maintainers, mostly @kelleyk I presume
Thanks.
--
chris
[Edit: fixed typos for clarity]
I agree there might be some packaging issue, since it seems I'm not the only one to daily run Emacs28 with native compilation on a debian/Ubuntu based system (at least @rcoacci does). And I'm not aware of any wide spread noise about Emacs native compilation being broken (if we ignore the NATIVE_FULL_AOT thing).
I also agree there must be something related to packaging because I've been using native compilation (including NATIVE_FULL_AOT) without any issues since before the release of 28.1, in both Ubuntu and CentOS systems (obviously compiled from sources). And I know from Reddit (and elsewhere) that I am not the only one using it daily so if there was some general breakage, we would have heard it by know.
Perhaps it's related to #24 and/or #16 ? I didn't see anyone in this thread commenting if they updated the packages (i.e. had emacs27 installed and upgraded to emacs28) or did clean installs (removing all emacs packages before installing emacs28). I know I did a clean install (freshly installed Ubuntu 22.04), and didn't have issues.
Perhaps it's related to #24 and/or #16 ? I didn't see anyone in this thread commenting if they updated the packages (i.e. had emacs27 installed and upgraded to emacs28) or did clean installs (removing all emacs packages before installing emacs28). I know I did a clean install (freshly installed Ubuntu 22.04), and didn't have issues.
I installed it on a more or less clean Ubuntu 22.04. When I saw that the ppa had been updated, I decided to try it immediately. But first I thought that I might as well go to the latest Ubuntu release, thinking that it will be the smoothest experience. So I replaced my Linux Mint 20 with Ubuntu Mate 22.04. After the OS install, I just ran my usual post-install setup script that does some very basic bash setup and installs the C, C++ and Python development tools that I normally use. Then I added the ppa and installed Emacs 28 and then ran into the issue discussed in this thread.
The description on the actual PPA page mentions kk-debuilder, which is part of a set of tools that I wrote a long time ago that runs the Debian tooling in a Docker container. The original goal was to improve repeatability and to make cross-building for other Ubuntu releases easier.
There are some details (and links to the other packages) in that README, but if you aren't in a hurry, it might be better to wait for me to put together some more detailed notes or a Docker-in-Docker version of the toolchain or something of that nature. I'm not sure that anyone other than me has ever used them, and they're quite old, so getting them going without directions might not be a good use of your time.
Once you have them working, though, a binary build is as easy as
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
$ kk-debuilder --target=jammy --no-check --debian-branch=master-emacs28.1-jammy --upstream-branch=upstream-emacs28.1
$ echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
Re: "there must be something wrong with the packaging"---I think my wording was unclear. I don't think that the upstream feature is broken, so in that sense of course it's something with the packaging. There are two main parts of the packaging, though: the build (and build configuration), and the part where the build products are shoved into packages. When I said that it pointed at there being something wrong with the packaging, I meant the second part.
Life has been a little busy for the past few days, but I'm still hoping to find some time to look at this in the near future.
Good news, guys. I think I found out at least one workaround.
I managed to build a package from master-emacs28.1-jammy using this https://github.com/tsaarni/docker-deb-builder/ and managed to reproduce the issue.
I've been thinking about what could be causing this issue for some time now, and was wondering if the problem is that the native compilation framework relies on the presence of the source .el files, so after reproducing the problem, I installed the emacs28-el package that was build, and bingo! The problem is gone.
So it seems that native compilation requires the presence of the source .el files to work correctly, at least in the way that it's build currently. So the easy solution would be to make the emacs main package depend forcibly on the emacs-el package. The hard solution would be to try to find out if there is an small subset of sources that are necessary or try to find if there is some way to build with native compilation without the needing the source files available.
Good news, guys. I think I found out at least one workaround.
Yes, I think were getting there, good spot.
I managed to build a package from master-emacs28.1-jammy using this https://github.com/tsaarni/docker-deb-builder/ and managed to reproduce the issue.
Thanks for the docker-deb-builder hint.
Although I could not complete the build with docker, that at least gave me the correct ala debian build command: dpkg-buildpackage -us -uc -ui -b (I've missed the -b option).
With this I've been able to build the -kk1 packages from master-emacs28.1-jammy, and reproduce the error.
I've been thinking about what could be causing this issue for some time now, and was wondering if the problem is that the native compilation framework relies on the presence of the source
.elfiles, so after reproducing the problem, I installed theemacs28-elpackage that was build, and bingo! The problem is gone.So it seems that native compilation requires the presence of the source .el files to work correctly, at least in the way that it's build currently. So the easy solution would be to make the emacs main package depend forcibly on the emacs-el package.
Emacs should not need the .el files, and just be happy with the .elc files that are included in the emacs28-common package (the compilation path is el -> elc -> eln, thus can resume at the elc stage).
IMHO, the issue is simply that these .elc files are (mostly) installed in the /usr/share/emacs/28.1/lisp/emacs-lisp directory, which is not part of the Emacs configured load-path.
The hard solution would be to try to find out if there is an small subset of sources that are necessary or try to find if there is some way to build with native compilation without the needing the source files available.
Another easy solution could be to just fix the Emacs load-path:
--- a/debian/rules
+++ b/debian/rules
@@ -94,6 +94,7 @@ local_lpath := $(local_lpath):/usr/local/share/emacs/$(runtime_ver)/site-lisp
local_lpath := $(local_lpath):/usr/local/share/emacs/site-lisp
local_lpath := $(local_lpath):/usr/share/emacs/$(runtime_ver)/site-lisp
local_lpath := $(local_lpath):/usr/share/emacs/site-lisp
+local_lpath := $(local_lpath):/usr/share/emacs/$(runtime_ver)/lisp/emacs-lisp
$(info *** Detected upstream_ver=$(upstream_ver))
$(info *** Detected runtime_ver=$(runtime_ver))Seems to works fine. I remove anything Emacs related on my computer, re-do the whole thing, and will report here if we're actually almost done with this issue.
Thanks.
--
chris
Emacs should not need the .el files, and just be happy with the .elc files that are included in the emacs28-common package (the compilation path is el -> elc -> eln, thus can resume at the elc stage).
Hmm, I didn't knew eln came from elc, I always assumed elc was optional or a byproduct when native-compiling.
But maybe you've got into something even better: perhaps the eln files themselves are missing from the load_path (or the equivalent for native compiled files) and that's what caused the issue in the first place?
Either way, this fix should probably be merged.
I'll try to find out about the eln load_path equivalent and see if that's also a problem, after all, we're compiling it and shipping it, it would be a waste if emacs wasn't using it.
Emacs should not need the .el files, and just be happy with the .elc files that are included in the emacs28-common package (the compilation path is el -> elc -> eln, thus can resume at the elc stage).
Hmm, I didn't knew
elncame fromelc, I always assumedelcwas optional or a byproduct when native-compiling.
It seems you're plainly right, and I'm a moron.
After my system wide and user wide (including ~/.emacs.d/eln-cache) clean-up, Emacs28 (-kk1, patch applied) opens, but basically fails with Warning (comp): Cannot look-up eln file as no source file was found for /usr/share/emacs/28.1/lisp/simple.elc.
Which directed me to Can't compile ELN if EL and ELC reside in different directories, and Emacs actually needs the .el file for native compilation (and also relies on the .el to get the hash).
But maybe you've got into something even better: perhaps the eln files themselves are missing from the
load_path(or the equivalent for native compiled files) and that's what caused the issue in the first place?
I'll try to find out about the elnload_pathequivalent and see if that's also a problem, after all, we're compiling it and shipping it, it would be a waste if emacs wasn't using it.
The few .eln files that are pre-compiled (without full AOT) are actually installed under /usr/lib/x86_64-linux-gnu/emacs/28.1/native-lisp/ which is included in the configured native-comp-eln-load-path.
Either way, this fix should probably be merged.
I'm afraid the .el Lisp sources are required anyway, which means installing emacs28-el, and with these the .elc files are useless: I think the right patch is rather what you've suggested, make the emacs28 package depends on emacs28-el.
You've reported another interesting thing: it seems you run a build with NATIVE_FULL_AOT enabled without any issue, which could help mitigating the pain some peoples feel during the initial packages compilation.
Thanks.
--
chris
@dottspina: you beat me to it, I was just writing a comment to say that in my installation, the load-path variable has /usr/share/emacs/28.1/lisp/emacs-lisp even before applying your fix, I'd guess that's a default path appended by emacs to /usr/share/emacs/28.1/lisp/, so this was probably not needed.
The few .eln files that are pre-compiled (without full AOT) are actually installed under /usr/lib/x86_64-linux-gnu/emacs/28.1/native-lisp/ which is included in the configured native-comp-eln-load-path.
I have also confirmed that.
I'm afraid the .el Lisp sources are required anyway, which means installing emacs28-el, and with these the .elc files are useless: I think the right patch is rather what you've suggested, make the emacs28 package depends on emacs28-el.
In that case, It might not make much sense to have a separate emacs28-el package, unless debian/ubuntu packaging rules demand it, or a no-native-compilation package is provided. Or the other way around: make a separate native-compilation package that depends on the emacs-el and keep the regular emacs package as is without native-compilation.
You've reported another interesting thing: it seems you run a build with NATIVE_FULL_AOT enabled without any issue, which could help mitigating the pain some peoples feel during the initial packages compilation.
What problems people have with NATIVE_FULL_AOT? I've always used it and never got any issues (except for huge build times when building emacs from source...). I've used it successfully with both Spacemacs and DoomEmacs (which IMHO are huge testbeds for emacs ;-) ).
I guess we need to give @kelleyk some time to catch up now :-)
Yes, fully agreed:
emacs28with native compilation should depend onemacs28-elto get the required.elfilesemacs28without native compilation should just be happy with the.elcfiles provided byemacs28-common
I also use Doom at times, will build Emacs with NATIVE_FULL_AOT enabled and see if I face any issue (can't remember where I've got this idea there where issues with this option).
I guess we need to give @kelleyk some time to catch up now :-)
Yes, certainly. At least I hope we were able to provide some help, not just spam.
Thanks.
--
chris
This thread is wonderful; thanks everyone for all of the sleuthing!
I'm going to try leaving native compilation disabled in the emacs28 packages and adding a series of emacs28-nativecomp packages that have the same configuration except with native compilation enabled. They will also add a dependency on emacs28-el for the reasons discussed above.
I think that this roughly lines up with where the conversation wound up---let me know if I missed anything!
I've uploaded packages and it looks like the first few have finished building! If you want native compilation, you'll need to install emacs28-nativecomp; I agree with what @phil-s said above. We can always re-evaluate making it part of the default package configuration in future releases, but the purpose of the PPA is to provide stable releases, so where there's any doubt, let's err on the side of caution.
Thank you again @dottspina, @rcoacci, and everyone else who has contributed to this thread. It's lovely and encouraging to see everyone working together to figure out what we should do!
I notice that Launchpad hasn't updated the Packages files in the PPA yet, which I'm hoping is a hiccup on their end and not a sign that the new packages have some exotic new problem. (You can download the packages directly, though; for example, here's emacs28-nativecomp for jammy). [Edit: They've updated, so you should be able to apt-get update && apt-get install emacs28-nativecomp now.]
I'll leave this issue open until we're sure that the packages are doing what we expect. Feedback on them is, as always, very welcome!
First, thanks @kelleyk,
Just removed my custom built packages and reinstalled your -nativecomp packages. So far it's working fine.
I have now installed the package emacs28-nativecomp from the ppa on Ubuntu Mate 22.04. It seems to work perfectly. No issues during installation. No issues loading my emacs config from before native comp. No issues while trying out my normal emacs workflow.
At first I didn't know if it was actually using native comp. I've heard so much about the initial lagg when emacs start compiling everything. But I felt nothing, and I'm even on a laptop(granted it's a laptop with a pretty strong CPU: Ryzen 7 5800H). So I thought that maybe I need to enable it with some elisp variable. But then I found a bunch of new files in a subfolder of my .emacs.d directory. So I guess it compiles everything asyncronously. Literally so smooth that I didn't even notice it!
Thanks a lot guys!
Works great for me too. Thank you!
Thanks for the reports, everyone! I'm going mark this resolved.
@kelleyk can you add a emacs28-nativecomp-nox package? Thank you.