Re: Windows binaries for emacs-28 status and TODOs

["H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>]

Corwin Brust <corwin@bru.st> writes:

> ==Priority Tasks==
> 1. uploading binaries to alpha.gnu.org

+1 (conditionally)

I hope, with this, there will be more feedback and tested use cases,
than we can provide.

> Eli, please weigh in on this point, especially.

Yes please.

> 2. fix any critical bugs specific to the binaries as I'm building them
> ..
> 3. better document the process for building windows binary releases

Sorry, haven't checked your documentation work yet.

> ==Open Discussion Points==
> 4. Should we have separate set with and without native compilation?

As a backup scenario in case of bug reports maybe? (I can't fathom what
might go wrong on Windows..)

> 5. Is the -static flag required for windows binary releases?

So far your build seems to work flawlessly on my MSYS machine.

By the way, are the debug symbols really necessary?  Eli mentioned this,
as far as I understood, as a reason for the bigger .eln file sizes
compared to files on Gnu-Linux.  Could we spare another, maybe,
unnecessary compiler flag?

> 6. What problems exist with the installer and how urgent is each?

    (debbugs-gnu-bugs 53551)
28.0.91; Installer on Windows10 (wishlist priority)

And then there is the "side-by-side" installation in existing Emacs' tree
issue..

> 6.1 Is the uninstaller doing the right thing in all cases?

    (debbugs-gnu-bugs 53553)
28.0.91; uninstall.exe leaves traces of Emacs

> 6.2 Should we detected existing Emacs install(s) and vary un/installer
> behavior accordingly?

At least in the long run, yes.  If Emacs is designed that way for
side-by-side installations..

> 6.3 Should we provide version specific copies of emacsclientw, runemacs, etc.?

Eli said: Not necessary.

> 6.4 Should we produce an MSI instead of (or in addition to) the installer exe?

MSI is another installer type, isn't it?  I think in my company .msi
files are not allowed to download by the virus scanners.  Might be an
issue for other users as well?

> I suggest, rather than rush to closure, we should proceed in parallel
> with those conversations/decisions and meanwhile focus on items 1-3.

+1

        Dieter