Subject: bug#74133: Wrong files attached

From: Corwin Brust <[email-masked]>
Date: Sun, 10 Nov 2024 13:35:47 -0600

> On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <[email-masked]> wrote:
>>
>> Corwin, are you looking at this?
>>

Hi Nikolas,

Thank you very much for working on this.  I suspect your code is good
- a big improvement.

Unfortunately, the local version that I have been using contains a
number of fixes that are lost when I apply your patches, some of which
are important, fixing issues that have been reported since the in-tree
version of build-dep-zips.py was last updated (for Emacs 28,
seemingly, but I'm not sure the currently in-tree version ever quite
worked for Emacs 28; certainly it does not for any newer version).
This is entirely my fault: I should have been pushing to get the
in-tree version in sync with what I have been using locally long
before this.

Even more embarrassingly, I'm not a strong enough python programmer to
puzzle out how to merge your changes in against mine.  As I mentioned
when we chatted, my only python coding has been trying to keep this
program working enough to use it to produce new deps and dep-sources
archives in preparation for a new major version of Emacs.  Left to my
own devices I would have replaced this script entirely given that
recent msys2 updates appear to have invalidated my work toward
introspecting (the just compiled) Emacs (replacing the hard-coded
DLL_REQ variable).  As I'm sure you recall from our chat, we cannot
simply use ntdll because the majority of the dependencies are
"optional", being loaded at the run-time if available. Since upgrading
and updating my msys2 install I'm unable to find a way to launch the
Emacs compiled for Windows from the msys2 msys shell in which this
python script must run.

All of this said, I think your patches are in the right direction and
will greatly improve upon what we have.  Thus, as the coup de gras of
this "pie-in-the-face" escapade, I must reward your hard work by
asking for harder and more tedious work still.  I'm entirely open to
suggestions; the approach I'm prescribing defends against regressions
(loss of any fix introduced in the script by me but not pushed to
emacs.git that solved some problem we encountered) in consideration of
my ignorance of and discomfort with python.

I have attached the version of the script that (so far) appears
successful for the emacs-30.0.92 set of binaries.  If you are willing,
I would like you to respin your patch against my version.  To restate:
the in-tree version from which you based your patches does not work:
it will not run on current versions of msys2.  If it did run, it would
produce results that would be both incorrect and incomplete.  For that
reason, I don't believe it would be a problem to push the version
attached to emacs.git if that makes your work easier.  Alternatively,
I believe you would be welcome to rewrite as much of the program as
you feel necessary, so long as we achieve identical results as I'm
able to get from the version I have attached to this message.  I will
test your work by ensuring that your new/patched version outputs
archives are identical to those produced by mine, currently the top
two items in this listing:

  https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/?C=M;O=D

As far as I know, I'm the only regular user of this program - given
the brokenness I've described I'm fairly confident of that.  Should
you be motivated toward further work on this, our goal will be fix
that - to enable others, by using this script, to more easily comply
with GPL when publishing their own builds of Emacs for Windows and to
more easily package "complete" Windows binaries distributions of Emacs
by using this "turn key" solution for collecting Emacs' dependencies
and their corresponding msys2 source archives.

Coming back to your patches, themselves, the one "note" I have is that
I would prefer not to omit the source-code comments (even where they
may be duplicative of the new docstrings you've suggested adding).

Again, thank you for your contribution and apologies for the various
of my failings that contribute to me being unable, simply, to push
them; I will certainly understand if you aren't inclined to invest
more time in this and would still welcome your comments and
suggestions regarding the best path forward (getting a working version
in-tree) in that event.

Warm regards,
Corwin