Subject: Re: bug#74133: Some minor patches for the python script

From: Stefan Kangas <[email-masked]>
Date: Thu, 13 Feb 2025 02:11:38 -0800

Corwin Brust <[email-masked]> writes:

>> 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

Nikolas, did you have a chance to look into the changes that Corwin
requested above?  Thanks in advance.