[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging MPS a.k.a. scratch/igc, yet again
From: |
Pip Cet |
Subject: |
Re: Merging MPS a.k.a. scratch/igc, yet again |
Date: |
Tue, 10 Dec 2024 14:46:11 +0000 |
On Tuesday, December 10th, 2024 at 04:17, Xiyue Deng <manphiz@gmail.com> wrote:
> Óscar Fuentes ofv@wanadoo.es writes:
> If making MPS available in Debian would help Emacs packaging I'm willing
> to work on this (in the coming weeks as igc may not land with the
> upcoming Emacs 30 release so not in a hurry.)
I think that would be great, even if we decide we cannot make do with an
unmodified upstream version of MPS.
> * Does igc require only mps.{h,c} or more sources from the MPS source
> package? It looks like there are many sources and it's autotools
> build script fails with GCC 14.2 in Debian Trixie due to several
> "-Werror"s. It may be easier to just compile and ship the required
> subset, though it may require providing a custom build script.
Ravenbrook recommends building the library directly by compiling mps.c, and
that's what I usually do. I still ended up having to remove -Werror from the
.mk files, at some point...
> * Does igc work with a dynamically linked MPS library?
It definitely does, because that's what we're using on Android. On other
systems, statically-linked code may be very slightly faster, but IMHO packaging
a statically-linked Emacs+MPS binary is problematic for a few reasons, just as
statically linking to libc would be. (It should go without saying that "we
always use it" is not sufficient reason for using a statically-linked library)
> Currently I have
> seen people suggesting that directly compiling the source, which is
> effectively like using MPS as a static library.
That works, and it's what I do on GNU/Linux, but we should probably change our
approach there.
> It would be less
> useful to package a static-only library in Debian because in case of
> any issues (usually security) updating the library is insufficient and
> its dependencies would need to be rebuilt as well. Using a dynamic
> library would solve this scalability issue, and it would be good to
> know if igc can work with a dynamically linked MPS.
It definitely can work, and I'll look into switching my builds over to using
dynamic linking.
> * Does igc work with the latest tagged version (release-1.118.0) or only
> the latest snapshot? Packaging a tagged version would be easier,
> though working with a snapshot may also work with a bit of extra
> efforts.
It's not quite clear to me yet whether we're going to be able to use unpatched
MPS on all architectures (that's somewhat unlikely) or on every architecture
except for 32-bit x86 (more likely).
Pip
- Re: Merging MPS a.k.a. scratch/igc, yet again, (continued)
- Re: Merging MPS a.k.a. scratch/igc, yet again, Xiyue Deng, 2024/12/11
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gregor Zattler, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Pip Cet, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gerd Möllmann, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gerd Möllmann, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Pip Cet, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gerd Möllmann, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/20
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gregor Zattler, 2024/12/20
- Re: Merging MPS a.k.a. scratch/igc, yet again,
Pip Cet <=
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/10
- Re: pdumper on Solaris 10, Stefan Kangas, 2024/12/09
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/10
- Re: pdumper on Solaris 10, Óscar Fuentes, 2024/12/10
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/10
- Re: pdumper on Solaris 10, Óscar Fuentes, 2024/12/10
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/10