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 14:53:15 +0100 Message-ID: <21e339147a2817352781e4abcc342bfb@russet.org.uk> 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> 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="22594"; 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 15:53:53 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 1k9Txw-0005nI-Ld for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 15:53:52 +0200 Original-Received: from localhost ([::1]:34456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9Txv-0004Jj-Oe for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 09:53:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9TxQ-0003tL-W4 for emacs-devel@gnu.org; Sat, 22 Aug 2020 09:53:21 -0400 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:59346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9TxO-0007xJ-MK; Sat, 22 Aug 2020 09:53:20 -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=0IVr482FdUcnWbGfgnXu00ZNMO/wdeugCiu6+FKU8Qo=; b=3UPlV5KMgTvm6khu2S3sjSzrAn RnjB+zt2SJ9r23kwmX/XYfJ16uJ1JeoynVD8dUjQFjaOtt0hG/UIPzaGisN/r41jWNYqBopJ0SYtX UjsyALmMnFrHrGMFzglnKa8SvSypyI/EtNi4ivXS0T6QhcOOmv17b6MtKFP2wIsrw7uC+w1ky4YYj VArPlkLdtAsRqOWpd+8s1gWKSBblMq0Feyc5/a5hUSNtpdN9c1p8CLpXlUPTz3BBXmimfyn/cZwuq tiwr+u/UlLnnv6IHqnHLoQwU2icQHIVV+yrHPvW1o5ix174OWBg089lUbWV2Orocm44uijovnW0gW 0EvHfAIg==; Original-Received: from [::1] (port=43880 helo=cloud103.planethippo.com) by cloud103.planethippo.com with esmtpa (Exim 4.93) (envelope-from ) id 1k9TxL-0007Et-RM; Sat, 22 Aug 2020 14:53:15 +0100 In-Reply-To: <83blj2akvl.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:254120 Archived-At: On 2020-08-22 14:08, Eli Zaretskii wrote: >> 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? 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. I could modify by test something like (ert-deftest (skip-unless (string-match-p "XPM" system-configuration-features)) (should (image-type-available 'xpm)) ) >> 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. >> > 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! >> 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. 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. >> > 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/. Having a test functionality under lisp/ does, I agree, seem morally wrong. Likewise `data-directory'. But, the reasons for it are clear, and what harm would it cause in practice? Phil