Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 14:58:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> >> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> >> remved the assert.
> >
> > Why did you do that?  What possible useful purpose can that serve?  If
> > the assertion gets in the way of what you are looking at, you can
> > always remove it locally, can't you?
> 
> Because PVEC_OTHER is handled fine now, except whatever w32 does in
> addition or maybe instead

Then maybe the assertion should be w32-only (if only w32 uses
PVEC_OTHER; I thought Helmut said he saw the same problem on
GNU/Linux?).  But removing it completely is not TRT, IMO.  We already
have quite a lot of code which was disabled under HAVE_MPS, and at
least some of that looks like workarounds for problems that got "low
priority".  I'm not sure this is a good way of making progress here,
especially since some of those #ifdef's could potentially cause
problems elsewhere.

I think we should methodically try to solve every problem we bump
into, without any priorities.  Priorities are fine when we want to
make a POC, to see if this is workable.  I think we are way past that
point, so leaving unsolved problems is no longer a useful methodology.

> (has it modules?)

Of course.  In a Windows build I have:

  load-suffixes
   => (".dll" ".elc" ".el")

> >> I'd say that xpostmortem wouldn't make sense during normal debugging,
> >> when MPS is not dead in the water. I don't think one can get out of that
> >> state again.
> >
> > I don't follow.  How is debugging problems with GC different from
> > "normal debugging"?
> 
> Imagine running Emacs under GDB and stopping at some breakpoint to debug
> whatever. You want to xbacktrace and then proceed with continue. That
> xbacktrace should not put MPS in post-mortem state.
> 
> > In any case, I asked about the downsides of calling igc_postmorten,
> > which I think is crucial to understand for making this decision.  If
> > there are no significant downsides, then doing so is a net win, no?
> 
> It's post-mortem = after death. MPS is then not in a usable state anymore.

It should have been obvious that I meant to do that after a crash.  I
admit I didn't say that explicitly, but I thought it was obvious.
Sorry.