[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging MPS a.k.a. scratch/igc, yet again
From: |
Eli Zaretskii |
Subject: |
Re: Merging MPS a.k.a. scratch/igc, yet again |
Date: |
Tue, 10 Dec 2024 15:20:14 +0200 |
> From: Xiyue Deng <manphiz@gmail.com>
> Date: Mon, 09 Dec 2024 20:17:54 -0800
>
> 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.)
Thanks in advance.
> I have a few questions regarding the Emacs/igc usage 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.
I suggest to use the detailed instructions under "Building the MPS for
development" in manual/build.txt. This is what I did, and had no
serious problems, even though I needed to concoct the various *.gmk
Makefiles because my platform was not supported OOTB (GNU/Linux is
supported OOTB). The reason I suggest that is that an official Debian
distro of MPS had better included the several different builds of the
library ("cool" and "hot"), and also included all the headers that any
program using MPS might need, even if Emacs uses just part of them.
The package should also include the Info manual, IMO.
> * Does igc work with a dynamically linked MPS library?
The MPS Makefiles build only static libraries, not shared libraries.
Since this library implements GC, and Emacs must have some GC, why
does it make sense to build MPS as a shared library?
> Currently I have
> seen people suggesting that directly compiling the source, which is
> effectively like using MPS as a static library. 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.
If you must build a shared library, you are basically on your own.
And doing that is in stark contrast to what you asked above about
headers used only by Emacs.
> * 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.
I built the official release, not a snapshot, FWIW.
- Re: pdumper on Solaris 10, (continued)
- Re: pdumper on Solaris 10, Stefan Kangas, 2024/12/08
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/09
- Merging MPS a.k.a. scratch/igc, yet again, Stefan Kangas, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, chad, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Xiyue Deng, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Sean Whitton, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, chad, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again,
Eli Zaretskii <=
- 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, Pip Cet, 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, Pip Cet, 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, 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