bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Tue, 15 Aug 2023 02:39:45 -0500
> Cc: 65206@debbugs.gnu.org
> 
> 5. Create a no-deps archive, essentially:
> 
>   zip -r9 ${PREFIX} emacs-${TARGET_VERSION_NAME}-no-deps.zip
> 
> 6. Unpack the deps archive created in step #2 (or the "last good", if
> that step was skipped), something like:
> 
>   unzip -d ${PREFIX}/bin ${LAST_GOOD_DEPS_ZIP_FOR_EMACS_MAJOR_VERSION}
> 
> 7. Create a "full" zip of Emacs (now including those "extra" DLLs),
> essentially repeating step #5 with a different archive file name  (in
> fact, I copy no-deps and re-add bin to it)
> 
> 8. Create the installer
> 
> 9. Perform certain rights and incantations to cause files to appear on
> GNU (alpha) FTP servers.  Notably, include new deps files ONLY when
> they have been newly created along with the release being published.
> These files have historically changed only rarely within a given Emacs
> major version.
> 
> > collect(s) the list of the dependency packages for the binary distro,
> 
> Ignoring my patch for the moment, the script contains two hard-coded
> lists that represent our first likely source of breakage:
> 
> DLL_REQ lists specific DLLs that should be copied into ${PREFIX}/bin,
> after make install, to get a "complete" Emacs installation.  During
> the Emacs 29 pre-release cycle I added sqlite3 and tree-sitter to this
> list, enabling those features to work "out of the box".  In some
> cases, such as these two in fact, Emacs would likely function
> correctly under Windows if we chose not to distribute a particular
> DLL; however, I believe this is not the case for all of DLLs included
> and, moreover (in my opinion) would tend to make Emacs to less viable
> as a means of drawing Windows users closer to Free Software by virtue
> of Just Being Better, which would be a bit sad.
> 
> PKG_REQ lists the mingw-w64-x86_64 source package name for each item
> in the first list.
> 
> These two variables are coordinated lists and so obviously could be
> refactored (e.g. into an associative array) that I suspect historical
> raisins (meaning, perhaps once these lists were not so coordinated; I
> didn't research this so far).
> 
> In addition to these "main lists" there are a few other vars/lines to
> study (now taking from my patched version):
> 
> SKIP_SRC_PKGS=["mingw-w64-gcc-libs"]
> SKIP_DEP_PKGS=["mingw-w64-glib2" "mingw-w64-ca-certificates-20211016-3"]
> 
> We'll come to the logic -where all of these are used-- next.
> 
> > including the main ideas and information sources[.  ...]
> 
> Ignoring as much complexity as possible by focusing on the
> release(like) use-case, we can ignore the arguments and conditions
> and, finally, we can reduce the the script to:
> 
> 2.1 evaluate above mentioned vars
> 2.2 collect all DLLs mentioned in DLL_REQ
> 2.3 collect the DLLs that are unique dependencies the DLLs collected
> in 2.2 skipping any which appear in SKIP_DEP_PKGS
> 2.4 collect the source for all DLLs from 2.2 and 2.3 unless the source
> package is listed in SKIP_SRC_PKGS
> 
> I hope I did cover information sources well enough, but to put a fine
> point on it: I watch Emacs devel, bug reports, IRC, reddit, ..., for
> information leading to updates to this script. Developers and others
> using Emacs on Windows are the main "information sources", at least
> speaking from developing that patch :)

Thanks.  What I still don't think I understand is how do you make sure
you have a full list of first-order dependencies?  I understand that
you mostly build on the "last good" list from previous release, but
since the list grows from time to time, what is the procedure for
finding the new dependencies, adding them to the list, and making sure
they all are there?

I'm asking because this is exactly where the procedure broke down when
we added WebP image support in Emacs 29.