Re: Building the igc branch on MS-Windows

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 13:55:53 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Could be some alignment problem?  MPS seems to use alignment of 4 on
>> > 32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
>> > objects?
>> 
>> The alignment of MPS objects is specified around line 2761 in igc.c
>
> (FTR: it's line 2908 now.)

Yes, I'm a bit lagging behind because I didn't want to rock the boat
while debugging the native compilation.

>>     MPS_ARGS_ADD (args, MPS_KEY_FMT_ALIGN, IGC_ALIGN);
>> 
>> IGC_ALIGN == GCALIGNMENT at present, which is 8 for me (USE_LSB_TAG).
>
> It's 8 for me as well, since that's Emacs's requirement since about
> forever.  But you are on a 64-bit platform, where MPS uses alignment
> of 8, whereas I'm on 32-bit, where MPS uses alignment of 4.  Can this
> be a problem for some reason?

I don't think so since we specify our own alignment.

>> > Backtrace #1:
>> > Backtrace #2:
>> 
>> No idea at the moment, but we should make sure to trace everything
>> reachable in a GUI frames first. Before that's done, it's basically
>> guaranteed to crash at soem point.
>
> Ah, okay.  I wasn't aware that such basics are not yet covered.  So,
> with the display stuff out of scope, what else is worth testing in
> this build?  

The glyph matrix stuff might actually work, for some value of work. Also
faces/cache. It's more the output_data stuff, fonts, maybe. Where things were
obvious, I tried to do at least something, like install ambig roots, and
such.

> Byte compilation works, as is shown by building the entire tree.
> Tree-sitter support needs finalizers to be ... ahm ... finalized
> first. What else is there that is supposed to work with the current
> source?

Great! I'm not using treesitter, so I haven't checked, but
the finalizers are there and should finalize, at least in theory.

Also interesting woujld be if igc_on_idle is called in the right place,
or if it could/should be called elsewhere. Igc_on_idle does 100ms of GC
work, and processes MPS messages (finalization, GC start, ...).

My plan after getting native-comp working, would have been to tackle
interactive use. Alas, I tripped over an LLDB problem yesterday that I
want to get out of the way first.

Anyway. Another interesting question would be how to possibly automate
(random) testing of the GUI somehow. Do we have something that goe sin
that direction?