From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: phillip.lord@russet.org.uk Newsgroups: gmane.emacs.devel Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted Date: Sat, 22 Aug 2020 16:13:52 +0100 Message-ID: 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> <83a6ymagux.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35099"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.4.6 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 22 17:14:44 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 1k9VEC-00092m-47 for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 17:14:44 +0200 Original-Received: from localhost ([::1]:32992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9VEB-0007bv-6h for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 11:14:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9VDR-0007C2-Sh for emacs-devel@gnu.org; Sat, 22 Aug 2020 11:13:57 -0400 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:36204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9VDP-0000hw-Fx; Sat, 22 Aug 2020 11:13:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=21nS5OpRcKqk7qCAT7nOlNJwPaBngADi4jmyNgJoFJI=; b=GCHU9t4jlmCTVL59bQQA0hqL9X fr3QzuEvcg4dydR4HSuATxCjyXmnoqfNyNiq4sGWote7xJQ75aGye1nyDju1ri2LQ4d/gc6fGBUHy yjoKqskQLENpaZ8EKucoFoiN4HyBdCSodn9nBEVwqWXxt2HOmNc+y3pbFqYt93vmvWZ/3u69otP6z 9hOsafzW0RhIFCKKR6CVW9pxGpFSQmU6xS5sloTPzlphHwraO+Px90oOOZGtMeH+9ZEZNh0XkCguq nJmDlt6VtRwa9gLUZ9BoCjcmIsGKyAb1+LDJnyZd17EYJMUQmySTiN4Px3WNrmFxfM8jIyLGE9p// RIfj302w==; Original-Received: from [::1] (port=48970 helo=cloud103.planethippo.com) by cloud103.planethippo.com with esmtpa (Exim 4.93) (envelope-from ) id 1k9VDM-0005Cb-V3; Sat, 22 Aug 2020 16:13:52 +0100 In-Reply-To: <83a6ymagux.fsf@gnu.org> X-Sender: phillip.lord@russet.org.uk X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk Received-SPF: none client-ip=78.129.138.110; envelope-from=phillip.lord@russet.org.uk; helo=cloud103.planethippo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/22 06:21:28 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:254123 Archived-At: On 2020-08-22 15:35, Eli Zaretskii wrote: >> Date: Sat, 22 Aug 2020 14:53:15 +0100 >> From: phillip.lord@russet.org.uk >> Cc: emacs-devel@gnu.org >> >> >> 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? So, there have been two problems with harfbuzz. First, when harfbuzz was installed, build-deps.py was not updated. A test system would not have picked this up. But someone complained about it in pre-release or snapshot builds. After that I added harfbuzz to build-deps.py, but it wasn't actually running. Iff I had added a test to w32-feature.el for harfbuzz, which this would have been discovered earlier. >> > 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. Indeed not. But, skipping a test because something is not compiled in is wrong iff the feature is supposed to be compiled in. Running "make check" on my windows build machine will only pick up errors with json parsing if libjansson was installed. It would nice to have a "make check" which assumes that all standard features (appropriate for the platform) are installed and fails (not skips). >> > 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. Because I have multiple admin directories, as I build both snapshot and release binaries. I do this by having a git worktree for emacs-27 and another for master. By putting the lisp test file in the distribution, I can guarantee that it is the right one. I am guessing that I would be the main user of this, and possibly the only user. It might be useful for anyone building Emacs binaries, however, so that they could check that their binary distribution has all of the standard features compiled in (or dynamically loadable). But this would require more logic as the standard features are not quite the same on all platforms, I think. It might also be useful for if someone reports that a feature is missing from a windows distribution that they have downloaded as it would provide a standard way of checking. Regardless, these are secondary issues. Right now, I want something that means I can check whether I have created a regression of the svg or harfbuzz issues. Without this, I am going to be very wary of trying alternative mechanisms for identifying dependencies; I still think that the windows binary distribution is unnecessarily complicated, based on the msys2 dependencies as given. Phil