From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted Date: Sat, 22 Aug 2020 16:08:30 +0300 Message-ID: <83blj2akvl.fsf@gnu.org> References: <83pn7oft7r.fsf@gnu.org> <5fd1bc533b4bfe603d106fb3ee816208@russet.org.uk> <83364keznu.fsf@gnu.org> <87imdgrlpq.fsf@telefonica.net> <83tuwzewxa.fsf@gnu.org> <87eeo3sxw0.fsf@telefonica.net> <47436f6137c965db141e290de6597fd5@russet.org.uk> <464a5bf221d1d77ea13381fb901931fd@russet.org.uk> <25cec7cf-804f-4777-9f88-295f1735e6c5_IMAP_ADDED_MISSING@UPANOVA> <4a785b99c43d27a7e7d7a231db6c8f06@russet.org.uk> <83wo1r9oen.fsf@gnu.org> <83ft8f9d5o.fsf@gnu.org> <83eenz9bir.fsf@gnu.org> <8373b3870aaea52590ee392bd6ff1ca9@russet.org.uk> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 22 15:09:27 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9TGx-000Aba-3W for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 15:09:27 +0200 Original-Received: from localhost ([::1]:32880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9TGw-0006OF-0f for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 09:09:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9TGC-0005wa-OC for emacs-devel@gnu.org; Sat, 22 Aug 2020 09:08:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37980) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9TGC-0003Hn-Ay; Sat, 22 Aug 2020 09:08:40 -0400 Original-Received: from [176.228.60.248] (port=2989 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9TGB-0006z6-N2; Sat, 22 Aug 2020 09:08:40 -0400 In-Reply-To: <8373b3870aaea52590ee392bd6ff1ca9@russet.org.uk> (phillip.lord@russet.org.uk) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254116 Archived-At: > Date: Sat, 22 Aug 2020 13:52:22 +0100 > From: phillip.lord@russet.org.uk > Cc: emacs-devel@gnu.org > > > I'm not talking about using ert or not, I'm talking about determining > > which of the features should check out and which shouldn't. Are you > > going to edit w32-features.el by hand each time you add or remove an > > optional library from the build? Or will the list of the features > > which should check out be constructed automagically somehow? > > It would be manual. The list of features changes rarely enough that it's > hard to automate this and know that it will work. The automation is as > likely to break as a manual system I don't understand why it must break, if you base it on system-configuration-features, or on some new file, to be generated by the build procedure. Did you consider one of these alternatives? If yes, why did you reject them? > If I think back to the bugs with Emacs binary releases, this would have > stopped only a few: harfbuzz and svg failure in this release. It would > not have prevented missing dependencies (I have missed all of harfbuzz, > lcms and libjansson till late in the day), nor the failed optimization > or stripping. I don't understand this, either. If the dependencies of HarfBuzz are not installed, then the HarfBuzz font backend will not be available, and the way I suggested for testing its availability will tell you HarfBuzz doesn't work, which is AFAIU what you wanted. And the same with any other DLLs: if their dependencies are not available, they will fail to load when the feature test runs, and the test will fail. > > If the latter, I didn't see you describe how will that happen. If the > > former, it means a file in the distribution will depend on the details > > of how you build the official binaries, which could be different from > > what end-users do on their systems (those who build their own Emacs), > > so the tests will fail for them, AFAIU. > > That is true with all of our tests, I think. No, our tests use skip-unless to avoid running tests that need features or programs which are unavailable. > json parsing is tested by make check and it will not work on msys2 > if the dependencies are not installed. I didn't look into this, but if json testing fails instead of skipping all the tests, that's a bug that should be fixed. > In this case, I am not suggesting adding ert tests to make check, > but a manually run test specifically for understanding the features > of a binary build. I am guessing anyone running this would be > understand what they are doing enough to know why. And I will > document the entry function. That's not what worries me. What worries me is the fact that a file distributed as part of the Lisp libraries will have its contents depend on the last release you personally did, with whatever quirks that required from the tests in that file. It doesn't sound right to me. > > It might also mean problems in merging from the release branch to > > master, > > e.g. if we remove some optional library from master that is still being > > used on the release > > branch. > > That problem is there anyway in build-deps.py But build-deps.py is under admin, whereas you are suggesting to do this under lisp/. > and it is worse there since it will break a release rather than fail > to test it. And I think for configure.ac also no? I'm not aware of such problems with configure.ac.