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

[Corwin Brust]

On Tue, Aug 15, 2023 at 11:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> >
> > I update the script as issues are reported or when I somehow otherwise
> > learn that changes are needed.  I have no real process for this, and
> > nothing in the tooling is helping me with it, so far.
>
> OK, so here's a suggestion which might improve that crucial part: scan
> the list in dynamic-library-alist, on lisp/term/w32-win.el.  Every
> dependency that is loaded dynamically (i.e., Emacs is not linked
> against it when it is built) must be in that list.  So when we add
> dependencies, we add them there.

I looked at the variable.   OT1H, it serves a very different use-case
("what are valid DLL names for a given library?" in the run-time, vs
"what DLLs should be sent along with Emacs?" in the build-time).
This means that meaningful hackery would likely be needed to
contemplate removing the hard-coded list completely, or even that we
would not be able to device any means of parsing this and choosing the
correct sent among DLLs present on the build system, to include.

OTOH, and more directly to the point of this bug report:

>
> I believe that given a full and complete lest of first-order
> dependencies, those which Emacs actually loads, all the higher-order
> dependencies can be found by following the MSYS2 pacman etc., is that
> right?
>

Right, that is how the script presently works:

    package_info = check_output(["pacman", "-Si",
pkg]).decode("utf-8").split("\n")

Thus, if we are content to have the script detect, and error demanding
correction when out of sync wrt `dynamic-library-alist', I believe it
can be done.  Moreover, IMO this will definitely help.

One process note is that I would likely switch to (maybe) generating
new DEPS right after creating NO DEPS, so the script can count on
invoking the freshly compiled and locally installed Emacs.  This also
seems much easier and also more proper vs anything to parse it "the
hard way".  (Especially so, considering complexities such as format
strings and the libpng version comment on the source setting up the
default value of dynamic-module-alist.)

Does a "invokes Emacs now and errors out if stuff is missing" approach
sound right/good?
Is it too soon for me to try making a new patch that explores this idea further?