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 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 > > 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 > >