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

Previous Next

Full log

Message #29 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 15:08:44 +0300

> From: Corwin Brust <corwin <at> bru.st>
> Date: Tue, 15 Aug 2023 20:23:44 -0500
> Cc: 65206 <at> debbugs.gnu.org
> 
> On Tue, Aug 15, 2023 at 11:01 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > 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.

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.  Given this, what problems do
you envision with using that list?

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

Great, that's what I hoped to achieve: a way of verifying that your
list of first-order dependencies is complete.

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

Previous Next

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