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

["Óscar Fuentes" <ofv@wanadoo.es>]

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.

Can you point me to a description of how MPS is related to compiler
optimizations and specifically to LTO?

>> * MPS does a correctness-critical job. Depending on multiple external
>> sources for such core component is a recipe for problems (future
>> changes by the MPS maintainers, patching by packagers, buggy
>> compilers, etc.) We need to keep a close watch on what MPS incarnation
>> we use. Better yet, total control.
>
> I think the correctness argument goes both ways: shared linking means
> bugs may be fixed for you automatically, as is routinely the case with
> libc.

libc is a central piece of any GNU/Linux distribution and therefore much
cared by the packagers. MPS not so. Fixes on minor packages like MPS can
take *years* to propagate through the distro universe, if at all.

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