[bug#44775] [PATCH] WIP: Add gccemacs

[Andrew Whatson <whatson@gmail.com>]

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