Re: Merging MPS a.k.a. scratch/igc, yet again

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Tue, 10 Dec 2024 16:37:28 +0100
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> >> * MPS does a performance-critical job. Using it as a shared object might
> >> incur in a performance penalty. Having it in source form alongside the
> >> Emacs sources will result in opportunities for optimizations (LTO,
> >> PGO, ...) that may bring better performance.
> >
> > ...and more problems. MPS has made the decision not to work with gcc
> > -O3, only with -O2 or less, and LTO in particular is something MPS
> > cannot reliably support, IIUC.
> 
> That sounds worrysome. If I understand the implications of what you
> wrote, MPS basically depends on what the specifics of what gcc does. But
> gcc can do something else on future versions... not to mention what
> happens if the user wants to use other compilers.

MPS does quite a few questionable things and depends on several
assumptions that are not easy to uphold.  We have already bumped into
some of them, with signals (like SIGPROF), for example, and don't yet
have a satisfactory solution, at least IMO.  It is hardly surprising
for a library that attempts to literally pull the rug from under the
feet of a running program.  We will probably find other issues as we
continue testing the branch.  That is why it's important for as many
people as possible to test it and report any problems.  That is most
of what is left to do on the branch before we decide it is ready to be
merged (or, unlikely, decide the problems are too much for us to cope
with).

> >> For those reasons, incorporating MPS into the Emacs sources is the right
> >> thing to do.
> >
> > I don't think that's an option, because Emacs should remain capable of
> > switching to GPLv4 if and when that is released, and we don't know
> > whether the MPS license is compatible with such a future document.
> 
> Yeah, the licensing point is what I was too afraid to mention :-)

We could alternatively fork the library and keep it in a separate
repository, under a different but compatible license.