Windows binaries for emacs-28 status and TODOs

[Corwin Brust]

Hi Eli, Dieter, Phil & Emacs devs,

I have confirmed that my latest binary packages are working.  When the
target system has a working msys64/mingw64 (with bin folder in the
windows path), native compilation is available.  It also works fine
for those without msys (however native compilation won't be available
in that case).  Thanks much to my kids for the use of their gaming
rigs, which I used for testing.

My latest work is in the with-native-compilation folder of this git repository:
  https://git.sr.ht/~mplscorwin/emacs-w64

Note that the builds in the parent directory are a touch older and
don't support native-compilation.  Also, this repo contains two
versions of a complete source dump for Emacs and each (recently
typical) release file:  it will take a lot of disc (~5GB) if you clone
the whole thing.  Consider hitting the repo URL in a web-browser and
using the "tree" tab to browse to and download what you need.

Since there have been several threads about building windows binary
releases for the emacs-28 pre-release, and those threads have gotten
quite long, I thought it would be good to start a new thread.

In addition to a summary of the related open discussion items/tasks, I
am attaching two files:
 - the first is my patch for build-zip.sh and build-dep-zips.sh
 - the second my ASCII armored GPG key

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

I'm happy to do this and have attached my GPG key, providing (what I
hope is) the proper information for Eli to forward to
ftp-upload@gnu.org if that is, indeed, desired.  I'm comfortable
making the directives files and there's an example in the root folder
of the repo linked above.

I'm fine if someone else would like to handle the "last mile", of
course.  More over, it will be best if at least one other person is
fully checked out on this (hi Dieter) and also able to push windows
binaries via FTP.  Getting things fully working involved some trial
and error for me.  That's why I'm considering better documentation of
the process (point #3) as an high priority.

Eli, please weigh in on this point, especially.

2. fix any critical bugs specific to the binaries as I'm building them

In short, I think there are none that should prevent us from
publishing the emacs-28 pre-repease to alpha.gnu.org.  That said,
there may well be things I'm missing. (First rodeo alert.)

I suspect that the patch attached (or as eventually corrected) should
probably be applied before Emacs 28 is released.  I'm not convinced
other code (or process) changes are necessary before release.  (Even
the attached patch is arguably a documentation improvement.)  For
details see the discussion points (4-6), below.

3. better document the process for building windows binary releases

While there are many opportunities whereby we may be able to improve
the process, I think it will be best to start by documenting how the
present process works.  We can then iterate though improvements taking
pains to keep our documentation current (in proper Emacs passion).

I've had a pretty powerful machine (still) running Microsoft Windows
on the "bare metal".  Even still, I'd likely not have succeeded
(certainly not as quickly) without the many emails back and forth,
especially with Dieter, Phillip, and Eli.   If there truly are not
concerns with these packages then as soon as they are uploaded (or
that task is otherwise assigned), I think that coleasing what I've
learned (while it is fresh) should be my priority.  I think that will
get (at least Dieter) to a place of building and perhaps publishing
the builds to the FTP site(s) fairly quickly.

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

This is the easiest of the discussion points, I think.  Eli has
suggested we can simply ship a native-comp enabled set of binary
release files assuming that is demonstrated to work.  I have satisfied
myself this does, in fact, work.  Moreover, no one has objected to
this approach.

FTR: I used three separate Windows machines, so far: one is where I'm
building the packages; the second has msys and native-comp does work
when I install there; the third has no msys (and had never seen Emacs
before) and there Emacs worked fine (but does not use the native
compiled elisp included in the build).

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

My present binaries seem to work without -static. If I haven't missed
something then I am satisfied -static isn't needed to create windows
binary release files.

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

I think we are actively discussing several relevant things:
6.1 Is the uninstaller doing the right thing in all cases?
6.2 Should we detected existing Emacs install(s) and vary un/installer
behavior accordingly?
6.3 Should we provide version specific copies of emacsclientw, runemacs, etc.?
6.4 Should we produce an MSI instead of (or in addition to) the installer exe?

I suggest, rather than rush to closure, we should proceed in parallel
with those conversations/decisions and meanwhile focus on items 1-3.
If discussion deems some fixes urgent, I (at least) will be happy to
create and/or push new pre-release versions as we go.

I hope we can "open up" the emacs-28 pre-release to feedback from
windows users who aren't able to build locally in time to do some
good.

Thanks so much for Emacs; HTH.

corwin_brust_gpg_key.txt
Description: Text document

emacs-28_nt-dist-build-scripts.patch
Description: Binary data