> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jb@jeremybryant.net, pipcet@protonmail.com, emacs-devel@gnu.org,
> eller.helmut@gmail.com, gerd.moellmann@gmail.com,
> stefankangas@gmail.com, acorallo@gnu.org
> Date: Wed, 21 May 2025 15:12:08 -0400
>
> >> >> Hmm... So we're thinking of "vendoring" MPS?
> >> >> I'm not very favorable to vendoring. It's often attractive in the short
> >> >> term, but it dumps extra work on distributions like Debian which will
> >> >> need to "unvendor" the library, and also can bring long-term maintenance
> >> >> cost to sync with other versions.
> >> > Why would they need to "unvendor" it, whatever that means?
> >> That's the principles/conventions they follow. As part of packaging,
> >> the "DM" has to make sure they don't end up with "hidden copies" of
> >> a library.
> > What is a "hidden copy" of a library?
>
> A copy of a library (such as MPS) bundled inside another package.
And why is that a problem for the distro, why do they have to make
sure it doesn't happen?
> >> >> So, I'd vote for "keep it as a separate library for now".
> >> > What do we do in that case with the platform-specific patches that
> >> > Emacs needs to apply to the library?
> >> Can we get them integrated upstream?
> > Unlikely.
>
> Why not?
Because patches submitted to them never got into the upstream, and bug
reports are still open. And because the last release was 2 years ago,
and the one before that 7 years ago. Look at their Issues: I see 10
issues there opened by Gerd, Pip, and others on behalf of Emacs since
more than a year ago, and they are still open. Can we live with such
level of support in a library that implements GC, which is one of the
most important functionalities in Emacs?
IMO, if we don't fork the library, we will need to maintain patches
and workarounds for it in the tree, which all but makes the advantages
of using an external library irrelevant.
Unless I'm misunderstanding how putting MPS into Emacs core source code would work, it doesn't seem like MPS would be a library at all. It would be part of the source code, compiled and linked akin to any Emacs .c file. If there is some concern over symbols being duplicated that might affect a dynamically-loaded module that itself uses MPS, I suppose that's a risk, if that's an issue at all?