| Git Clone URL: | https://aur.archlinux.org/emacs-git.git (read-only, click to copy) |
|---|---|
| Package Base: | emacs-git |
| Description: | GNU Emacs. Development master branch. |
| Upstream URL: | http://www.gnu.org/software/emacs/ |
| Keywords: | development editor IDE text |
| Licenses: | GPL3 |
| Conflicts: | emacs |
| Provides: | emacs |
| Submitter: | toropisco |
| Maintainer: | toropisco |
| Last Packager: | toropisco |
| Votes: | 109 |
| Popularity: | 1.93 |
| First Submitted: | 2014-01-05 02:05 (UTC) |
| Last Updated: | 2023-10-14 18:36 (UTC) |
Hi, folks.
I've forked¹ this repo to track the just-created emacs-28² release branch.
Also, I've enabled JIT and AOT, as well as parallel compilation.
Thanks, and happy hacking!
¹: https://aur.archlinux.org/packages/emacs28-git/
²: https://lists.gnu.org/archive/html/emacs-devel/2021-09/msg02290.html
A quick hack, not a proper solution as it would require some new functions and code reshuffling to have a proper cache, be it in a system-wide location in /var/cache or the user home directory, under .emacs, and a way to incrementally update already compiled files if the runtime version or the lisp file version changes.
Solving that upstream bug will be very difficult and I'll wait for an upstream solution
Apparently it was trivial to work around.
https://github.com/emacs-mirror/emacs/commit/663fb3b774887d3d15a6791c3f35af56daa3c676
Rebuilt from current master and everything appears to be working as expected.
Thanks for the reply and maintaining this script.
@nowayman, but of course it will. There's one thing I've learned in some 30 years plus of using and being the administrator of Unix and Unix-like multi-user servers and individual workstations: Never f*k with system directories.
Solving that upstream bug will be very difficult and I'll wait for an upstream solution. In the meantime my suggestions and be advised I don't recommend nor endorse you use them, I'll throw my experience behind a big no:
Install emacs with its own group and read-write permissions to the group. Add users to that group so that they can happily JIT compile system elisp files.
Install emacs with suid root giving users the chance to JIT compile on demand system elisp files and f*k up anything they would like to edit and save.
There are two reasonable solutions:
Precompile ALL system elip files, the option is already given in the PKGBUILD (AOT). Takes a long time but it is worth it.
Use sudo.
PKGBUILD Commit dca21d8 (Change behavior of changing directory ownership during packaging)
breaks JIT native compilation on my system.
Emacs installs fine, but when any packages along /usr/share/emacs/28.0.50/lisp/*
are loaded, the JIT compilation kicks in and throws a file-error due to directory permissions.
Compiling /usr/share/emacs/28.0.50/lisp/emacs-lisp/backtrace.el...
/usr/share/emacs/28.0.50/lisp/emacs-lisp/backtrace.el: Error: File error Creating file with prefix
This error message is incomplete, but that's a separate upstream issue. You can get the full error by manually attempting to compile any of those files from a shell prompt. e.g.
$ emacs -batch -l comp -f batch-native-compile
/usr/share/emacs/28.0.50/lisp/progmodes/etags.el
Which will throw:
Debugger entered--Lisp error: (file-error
"/usr/share/emacs/28.0.50/lisp/progmodes/etags.el" "Creating file with prefix"
"Permission denied" "/usr/share/emacs/28.0.50/lisp/progmodes/etags.elc")
signal(file-error ("/usr/share/emacs/28.0.50/lisp/progmodes/etags.el"
"Creating file with prefix" "Permission denied"
"/usr/share/emacs/28.0.50/lisp/progmodes/etags.elc"))
comp--native-compile("/usr/share/emacs/28.0.50/lisp/progmodes/etags.el")
batch-native-compile()
command-line-1(("-l" "comp" "-f" "batch-native-compile"
"/usr/share/emacs/28.0.50/lisp/progmodes/etags.el"))
command-line()
normal-top-level()
EDIT:
Looks like Eli may consider this an upstream bug altogether. Upstream bug report:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-06/msg00654.html
hi there, i think systemd should be add to makedepends. without it, group games wont be created, which causes chown root:games to fail when building the package in a clean chroot.
Your argument is a false dilemma and it stinks of appeal to ignorance.
If you don't like the ability to customize it to your needs, write and maintain your own version. As easy as that.
My point was that enabling/disabling lto is a setting inside makepkg.conf, so it shouldn't be set inside a package, unless a package needs to explicitly disable it, similar to packages using -j1 because -jN isn't supported. lto can be enabled in makepkg.conf, so it doesn't need to be in the PKGBUILD.
@cobaltspace lto is not enabled in the new makepkg.conf file. Unless you did in the past and forgot about it, the only plausible explanation for your alternate reality assertion. :-)
Compare your local file to this one:
https://github.com/archlinux/svntogit-packages/blob/packages/pacman/trunk/makepkg.conf
Now that setting lto is part of makepkg.conf, maybe the setting should be removed from this pkgbuild.
Pinned Comments
toropisco commented on 2017-06-30 19:14 (UTC) (edited on 2022-05-15 13:26 (UTC) by toropisco)
This PKGBUILD is a work in progress. If you find PACKAGING bugs, please let me know ASAP.
Upstream bugs are to be reported upstream. Check out the emacs-devel archives to confirm if this is an already known bug. In fact... Why are you not subscribed to
emacs-devel?. Also check theemacs-bug-trackerarchives.Reporting bugs: Write to the Emacs Bug Tracker and report it there. Or, better yet, use the
debbugsclient included with the text editor. You will find instructions at https://debbugs.gnu.org/. Good luck!If you confirm it is a packaging bug, you are welcome to report it here.
Yaourt and other automated tools users BEWARE! This PKGBUILD is written with hand updating in mind and I won't fix bugs arising from such use. Besides, cloning the same repository time and time again from a non-profit such as the GNU Project/FSF gives out a very low image of you.