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 14:15:56 +0300 Message-ID: <83eenz9bir.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18158"; 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 13:16:36 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 1k9RVj-0004eR-VF for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 13:16:35 +0200 Original-Received: from localhost ([::1]:57558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9RVj-0002an-16 for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Aug 2020 07:16:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9RVE-0002Ba-GW for emacs-devel@gnu.org; Sat, 22 Aug 2020 07:16:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37131) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9RVD-0000b7-Sd; Sat, 22 Aug 2020 07:16:03 -0400 Original-Received: from [176.228.60.248] (port=4007 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9RVD-0000Uz-8m; Sat, 22 Aug 2020 07:16:03 -0400 In-Reply-To: (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:254112 Archived-At: > Date: Sat, 22 Aug 2020 11:53:54 +0100 > From: phillip.lord@russet.org.uk > Cc: emacs-devel@gnu.org > > On 2020-08-22 11:40, Eli Zaretskii wrote: > >> Date: Sat, 22 Aug 2020 11:21:27 +0100 > >> From: phillip.lord@russet.org.uk > >> Cc: emacs-devel@gnu.org > >> > >> > The correct answers can be found by comparing against > >> > system-configuration-features, I think. > >> > > >> > And you have the same problem with your ERT-based approach, no? > >> > >> > >> No, because the correct answers are hardcoded into the file. > > > > I'm confused: how can you know the correct answers in advance in one > > case, but not in the other? > > I think we are talking cross purposes. Maybe so, but please bear with me, okay? > I do not want to display all the output, I want to know what it > should be. And I don't care about the output from things that work > as expected only things that do not. All of this is what ert is > designed for. I might like to tweak the output a little, but as ert > doesn't have a pluggable interface, that's harder. 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? 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. 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. I guess what I'm saying is that I don't yet see the overall picture of how this is supposed to work. Apologies if I'm missing something.