| > On Sat, Nov 2, 2024, 08:05 Eli Zaretskii <eliz@gnu.org> 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
|