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 17:35:18 +0300 Message-ID: <83a6ymagux.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> <83blj2akvl.fsf@gnu.org> <21e339147a2817352781e4abcc342bfb@russet.org.uk> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36792"; 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 16:36:02 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 1k9Ucj-0009S9-5a for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 16:36:01 +0200 Original-Received: from localhost ([::1]:40704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9Uci-0004Jt-6c for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 10:36:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9UcC-0003cp-L1 for emacs-devel@gnu.org; Sat, 22 Aug 2020 10:35:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38604) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9UcC-0003uv-3Q; Sat, 22 Aug 2020 10:35:28 -0400 Original-Received: from [176.228.60.248] (port=4318 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9UcB-0002LJ-GZ; Sat, 22 Aug 2020 10:35:27 -0400 In-Reply-To: <21e339147a2817352781e4abcc342bfb@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:254121 Archived-At: > Date: Sat, 22 Aug 2020 14:53:15 +0100 > From: phillip.lord@russet.org.uk > Cc: emacs-devel@gnu.org > > > 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? > > I didn't consider it much. I cannot see how to go from this to something > I can test. Say, `system-configuration-features` lists "XPM", I cannot > turn that into something I could test. You'd need a database of features like XPM vs tests to test each feature. This assumes we are talking about a general-purpose feature-testing facility of the kind proposed by Stefan, which I'm no longer sure is the case, see below. > I could modify by test something like > > (ert-deftest > (skip-unless (string-match-p "XPM" system-configuration-features)) > (should (image-type-available 'xpm)) > ) Yes, this would also be good. > >> 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. > > It would work if, when harfbuzz was installed w32-features was updated, > but not if it wasn't. As the harfbuzz merge didn't update build-deps.zh > which it arguable should have, then why would a test file be updated. Then I don't understand what you said in the quoted part above: you seemed to be saying that you could have detected the absence of HarfBuzz, but not of its dependencies. Which is why I wrote that having HarfBuzz without the dependencies will cause loading HarfBuzz to fail, and Emacs will think that HarfBuzz is not available. It doesn't matter whether the HarfBuzz DLL or its dependency DLLs are missing: in both cases the HarfBuzz DLL will fail to load. IOW, I thought you were describing the situation where w32-features _was_ updated to add a test for HarfBuzz. If not, then how could you have discovered that the DLL itself is not in the bundle? > >> > 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. > > I think you are correct about all of these. In either case, the tests > will not pass! Skipping a test and failing a test is not the same. You are looking for failures: tests that should have succeeded, but didn't. > > 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. > > Not sure I understand this. A lisp library with "w32-" in it's name will > have behaviour which reflects how the official binaries are supposed to > behave. If this worries you, as I say, I can add it to `data-directory' > instead. But, it has to be in the distribution. I thought we were talking about a feature that could serve any end user, including those who build their own Emacs, not just the person who produces the official binaries. If this is only about the official binaries, then why does it have to be under lisp/? Where you build the binaries, you always have the admin/ directory, albeit not in the distribution zip, so how can its being in admin/ be a problem for you? You should be able to invoke the test file from any directory on your system, not just from the unpacked archive.