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

Previous Next

Full log

Message #35 received at 65206 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: 65206 <at> debbugs.gnu.org
Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken
 and hard to maintain
Date: Wed, 16 Aug 2023 17:49:28 +0300

> From: Corwin Brust <corwin <at> bru.st>
> Date: Wed, 16 Aug 2023 08:41:25 -0500
> Cc: 65206 <at> debbugs.gnu.org
> 
> On Wed, Aug 16, 2023 at 7:08 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > 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?

Yes.

> 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

You can ignore those: they are for Windows 9X, and they are system
DLLs.

> gobject
> gio

These are needed for librsvg.  You might get away with them because
librsvg pulls them in as second-order dependencies.

> 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

Yes, this is required by libwebp, since some of the library functions
are in lobwebpdemux.

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

You should only skip the first two, which are Windows system DLLs.

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

OK.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.