Message ID | 874kljnk8z.fsf@asu.edu |
---|---|
State | Work in progress |
Headers | show |
Series | [bug#44775] WIP: Add gccemacs | expand |
Context | Check | Description |
---|---|---|
cbaines/applying patch | fail | View Laminar job |
cbaines/issue | success | View issue |
Hi John, On Sat, 21 Nov 2020 at 01:15, John Soo <jsoo1@asu.edu> wrote: > I was curious how fast this gccemacs branch might be, so I got it to > compile. Thanks! This motivates me to resume what had been discussed here [1]: be able to somehow run: --8<---------------cut here---------------start------------->8--- guix build emacs-magit emacs-foo emacs-bar --with-input=emacs=gccemacs --8<---------------cut here---------------end--------------->8--- At least, have a package transformation that allow to rebuild all the Emacs packages with the ’gccemacs’ VM instead of the current Emacs 27 one. > It feels fast but there are bugs and the closure is huge. Also these > patches do not use any of the parameterization machinery. What do you mean by “parameterization machinery”? The new ’with-parameter’ introduced here [2] or the package transformation that replaces all the dependencies (explicit and implicit). 1: <https://yhetil.org/guix-bugs/868scwtt34.fsf@gmail.com/> 2: <https://yhetil.org/guix-devel/87eeku8trb.fsf@gnu.org> All the best, simon
Hi zimoun, zimoun <zimon.toutoune@gmail.com> writes: > Thanks! This motivates me to resume what had been discussed here [1]: > be able to somehow run: > > guix build emacs-magit emacs-foo emacs-bar --with-input=emacs=gccemacs > > At least, have a package transformation that allow to rebuild all the > Emacs packages with the ’gccemacs’ VM instead of the current Emacs 27 one. > > >> It feels fast but there are bugs and the closure is huge. Also these >> patches do not use any of the parameterization machinery. > > What do you mean by “parameterization machinery”? The new > ’with-parameter’ introduced here [2] or the package transformation that > replaces all the dependencies (explicit and implicit). > > > 1: <https://yhetil.org/guix-bugs/868scwtt34.fsf@gmail.com/> > 2: <https://yhetil.org/guix-devel/87eeku8trb.fsf@gnu.org> I am referring to https://yhetil.org/guix-devel/87eeku8trb.fsf@gnu.org --with-parameter=gccemacs or similar seem to be required since the native-comp branch requires a different source, configure flags, and probably native-search-paths at least. There appears to be a separate compiled artifact directory under $out/lib/emacs/$version/native-lisp/$version-triple which has the compiled native libraries (.eln files). That directory seems to not be in the search path. That appears to be causing the first error I see. I am not sure which env variable would be tweaked to pick those paths up. Hope that helps! John
Have you seen this gccemacs package? I haven't looked into it myself but it might help you. https://github.com/flatwhatson/guix-channel
Hi Morgan, Thank you! I will take a look. If I end up using some of their code, should I consult them about it and see if they want a copyright line? How is that supposed to work? Thank you again, John
Hi John, (And hi Andrew. We're discussing including your code into the main Guix repository. You can view the full conversation here: https://issues.guix.gnu.org/44775) The code I linked to is already licensed under GPLv3+ meaning that you are free to integrate their code into the Guix code-base (Going to put here that I'm not a lawyer and that this is not legal advice and might not even be correct). You should indeed put a little copyright line for Andrew in the code. The exact copyright line you should use seems to be this (pulled from their git repo): ;;; Copyright © 2020 Andrew Whatson <whatson@gmail.com> You can do all this without contacting the author, but hopefully Andrew responds to us with lots of love. Thanks, Morgan On 12/11/20 3:40 PM, John Soo wrote: > Hi Morgan, > > Thank you! I will take a look. If I end up using some of their code, > should I consult them about it and see if they want a copyright line? > How is that supposed to work? > > Thank you again, > > John >
Hi everyone, Yes, I'm very happy for my work to be included in Guix in whatever form. I've detailed my work below, and also CC'd Andrea who is responsible for developing this feature in case he has anything to add. 1. Enable the `--with-native-comp` configure flag. Self explanatory! 2. Set the `NATIVE_FULL_AOT=1` make flag, maybe. This tells the build process to native-compile *all* of the Elisp that ships with Emacs. Otherwise only the minimal set of Elisp packages included in the pdump will be native-compiled, with the rest to be compiled on-demand at runtime. This has a significant impact on compilation time, so makes more sense if the package will be built once and installed many times, and less sense if everyone is building the package themselves. 3. Extend `LIBRARY_PATH` so libgccjit works at compile time. This is necessary for a functioning libgccjit and to pass the "smoke test" in the configure script. I think this should probably be exported by the libgccjit package as a search path instead of requiring all dependents to handle it manually. 4. Patch the `comp-native-driver-options` in `comp.el`. This is necessary to have libgccjit functioning at runtime. Originally I was setting LIBRARY_PATH in the emacs wrapper to achieve this, but that had the undesirable effect of leaking to any process launched from Emacs. Setting the necessary paths via the driver options is a much more targeted solution. 5. Remove the shell-script wrappers from eln files. The `glib-or-gtk-build-system` aggressively wraps anything which smells like an executable, preventing the native-compiled Elisp from being loaded as shared libraries at runtime. This is based on the `restore-emacs-pdmp` phase in the base Emacs package which works around the same problem. 6. Use a newer `libgccjit` based on `gcc-10`. This is not strictly necessary, but if I recall correctly libgccjit-9 suffers from a bug related to the inlining of constant strings which was fixed in libgccjit-10, and this has some impact on the performance of native-compiled Elisp. The `libgccjit` package in Guix is only defined for gcc-9, so I created a package factory to define libgccjit packages based on an arbitrary gcc, and use gcc-10 and libgccjit-10 as dependencies for the emacs-native-comp package. I haven't tried to build using gcc-9 and libgccjit-10, so I'm not sure if there's some interdependency. I think it would be best to upstream libgccjit-10 alongside an emacs-native-comp package. I hope this all makes sense, happy to answer any questions. Cheers, Andrew On Fri, 18 Dec 2020 at 03:26, Morgan Smith <Morgan.J.Smith@outlook.com> wrote: > > Hi John, > > (And hi Andrew. We're discussing including your code into the main Guix > repository. You can view the full conversation here: > https://issues.guix.gnu.org/44775) > > The code I linked to is already licensed under GPLv3+ meaning that you > are free to integrate their code into the Guix code-base (Going to put > here that I'm not a lawyer and that this is not legal advice and might > not even be correct). You should indeed put a little copyright line for > Andrew in the code. The exact copyright line you should use seems to be > this (pulled from their git repo): > > ;;; Copyright © 2020 Andrew Whatson <whatson@gmail.com> > > You can do all this without contacting the author, but hopefully Andrew > responds to us with lots of love. > > Thanks, > > Morgan > > On 12/11/20 3:40 PM, John Soo wrote: > > Hi Morgan, > > > > Thank you! I will take a look. If I end up using some of their code, > > should I consult them about it and see if they want a copyright line? > > How is that supposed to work? > > > > Thank you again, > > > > John > >
Hi John, On Tue, 24 Nov 2020 at 07:06, John Soo <jsoo1@asu.edu> wrote: >> Thanks! This motivates me to resume what had been discussed here [1]: >> be able to somehow run: >> >> guix build emacs-magit emacs-foo emacs-bar --with-input=emacs=gccemacs >> >> At least, have a package transformation that allow to rebuild all the >> Emacs packages with the ’gccemacs’ VM instead of the current Emacs 27 one. >> >>> It feels fast but there are bugs and the closure is huge. Also these >>> patches do not use any of the parameterization machinery. >> >> What do you mean by “parameterization machinery”? The new >> ’with-parameter’ introduced here [2] or the package transformation that >> replaces all the dependencies (explicit and implicit). > I am referring to https://yhetil.org/guix-devel/87eeku8trb.fsf@gnu.org > > --with-parameter=gccemacs or similar seem to be required since the > native-comp branch requires a different source, configure flags, and > probably native-search-paths at least. I am not convinced that the “parameterization machinery” could help here (aside it is far to be ready :-)) because in this case, “gccemacs” is not a «parameter» but an «argument» of the Emacs build system. Maybe I miss something. > There appears to be a separate compiled artifact directory under > $out/lib/emacs/$version/native-lisp/$version-triple which has the > compiled native libraries (.eln files). That directory seems to not be > in the search path. That appears to be causing the first error > I see. I am not sure which env variable would be tweaked to pick those > paths up. Thanks for the explanations. All the best, simon
Most versions of Emacs available on the guix master branch make use of this work to make everything blazing fast, so thanks. Closing.
From f23ebabab5e57b22b45fea3a26f9a1814331f39a Mon Sep 17 00:00:00 2001 From: John Soo <jsoo1@asu.edu> Date: Sat, 21 Nov 2020 00:59:14 -0800 Subject: [PATCH 3/3] gnu: Add gcceamcs-no-x. * gnu/packages/emacs.scm (gccemacs-no-x): New variable. --- gnu/packages/emacs.scm | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index 6312fde3ad..721a13f429 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -487,6 +487,26 @@ editor (from the native compilation branch)") ((#:configure-flags flags ''()) `(cons "--with-nativecomp" ,flags)))))) +(define-public gccemacs-no-x + (package/inherit emacs-next-no-x + (name "gccemacs-no-x") + (version gccemacs-version) + (source gccemacs-source) + (synopsis "The extensible, customizable, self-documenting text +editor (console only, from the native compilation branch)") + (build-system gnu-build-system) + (inputs + `(("libgccjit" ,(canonical-package libgccjit)) + ,@(package-inputs emacs-next-no-x))) + (arguments + (substitute-keyword-arguments (package-arguments emacs-next-no-x) + ((#:phases p) + `(modify-phases ,p + (add-after 'bootstrap 'add-libgccjit-gcc-lib-to-library-path + ,add-libgccjit-gcc-lib-to-library-path))) + ((#:configure-flags flags ''()) + `(cons "--with-nativecomp" ,flags)))))) + (define-public emacs-no-x-toolkit (package/inherit emacs (name "emacs-no-x-toolkit") -- 2.29.1