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

[Xiyue Deng]

Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> On Tuesday, December 10th, 2024 at 13:10, Óscar Fuentes <ofv@wanadoo.es> 
> wrote:
>> Xiyue Deng manphiz@gmail.com writes:
>> * It is very likely that we end doing some patching to the MPS sources
>> to adapt to our specific needs (if those patches end upstream or not,
>> that's another question.)
>
> If that ends up being the case, we'll have to make sure not to use shared 
> libraries which may contain the upstream code. But that's true of all 
> libraries; in the particular case of a Debian package, both the APT 
> versioning schemes and ELF versioning are available for that.
>

I think it's possible to package a specifically customized variant of
MPS for use of Emacs, which can specify compiler options or even carry
patches specifically for use of Emacs.  It would be good to be able to
work with vanilla MPS to avoid this extra maintenance burden, of course.

>> * 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.
>
>> * 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.
>
>> 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.
>
> So it's either static or dynamic linking; static links have these 
> disadvantages:
>
> * shared libraries on GNU/Linux have versioning, static libs don't, AFAIK
> * legally, statically-linked binaries are quite different from 
> dynamically-linked ones
> * someone might enable LTO and break MPS (this may be done automatically by 
> the compiler rather than a user error)
> * with dynamic linking, there is some hope we could switch from libmps.so to 
> libmps-debug.so without having to recompile Emacs, which would help us 
> diagnose crashes in their actual environment
>

Thanks for the summary!

I would hope using dynamic linking would not be a deal breaker, and the
advantages vs a static lib you listed are good from distribution point
of view.

> Pip
>

-- 
Regards,
Xiyue Deng

signature.asc
Description: PGP signature