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

[Corwin Brust]

On Wed, Aug 16, 2023 at 7:08 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Tue, 15 Aug 2023 20:23:44 -0500
> > Cc: 65206@debbugs.gnu.org
> >
> > On Tue, Aug 15, 2023 at 11:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > the list in dynamic-library-alist, on lisp/term/w32-win.el.
>
> I'm not sure I understand the reservation.  That list mentions every
> single DLL that we know can be used for each optional feature.  If a
> feature has more than one DLL listed, the first one is usually the
> most popular, and should be tried first.

This solves my worry completely, or nearly so.

To confirm: when walking the list, I will want to take the first DLL
mentioned that actually exists for each entry. Is that right?

> Given this, what problems do you envision with using that list?

There might not be a problem (except the one we are trying to fix).
The alist contains 22 entries, while var DLL_REQ contains 14 entries.
The five on the alist but on mentioned in the script (so far) are:

gdiplus
shlwapi
gobject
gio
webpdemux - this is pretty obviously a miss in the script; it does get
however because it's required by webp which is listed in DLL_REQ

Are all of these errors with the script (so, the corresponding DLLs
should be included)?  If not, I think we will need a way for the
script to know which alist entries to skip/ignore.

> > Does a "invokes Emacs now and errors out if stuff is missing" approach
> > sound right/good?
>
> I'm not sure I understand how would you force Emacs to "error out"
> when we are talking about optional dependencies.  They are optional so
> that Emacs could run even if they are not present.
>

Oops, badly said:  I mean that my build and packaging process should
stop and report an error if it cannot create a "complete" DEPS ZIP.
Nothing affecting the Emacs run-time.