From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 15 Oct 2022 12:00:23 -0500 Message-ID: <87fsfpggyg.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <83sfk6ahty.fsf@gnu.org> <8735c6b0wo.fsf@gnus.org> <87y1ty9lha.fsf@gnus.org> <87lepym6ok.fsf@trouble.defaultvalue.org> <877d1i9h7k.fsf@gnus.org> <83edvqyr3q.fsf@gnu.org> <874jwl8e4p.fsf@gnus.org> <87pmf64beo.fsf@gnus.org> <87h70i4a46.fsf@gnus.org> <83tu4irzl1.fsf@gnu.org> <87y1ttsrve.fsf@yahoo.com> <83r0zlqxcr.fsf@gnu.org> <87fsfqi95f.fsf@trouble.defaultvalue.org> <83v8om6x8u.fsf@gnu.org> <87v8omgl4r.fsf@trouble.defaultvalue.org> <83sfjp7g4i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8665"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, larsi@gnus.org, akrl@sdf.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 19:03:00 2022 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 1ojkYu-00024s-7H for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 19:03:00 +0200 Original-Received: from localhost ([::1]:58176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojkYs-0001bo-T4 for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 13:02:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojkWS-0000kT-Qs for emacs-devel@gnu.org; Sat, 15 Oct 2022 13:00:28 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37494) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojkWR-0001eO-4L; Sat, 15 Oct 2022 13:00:28 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 9645C20654; Sat, 15 Oct 2022 12:00:24 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 841B414E081; Sat, 15 Oct 2022 12:00:23 -0500 (CDT) In-Reply-To: <83sfjp7g4i.fsf@gnu.org> Received-SPF: pass client-ip=45.33.119.55; envelope-from=rlb@defaultvalue.org; helo=defaultvalue.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:297800 Archived-At: Eli Zaretskii writes: > I meant HOME=/does-not-exist, yes. If that doesn't work (but please > test), we should fix that, I think. Please report your findings if > that doesn't work. We use that in our own test suite. I've been told that it doesn't because (the person thought) of trampolines. i.e. Emacs can be reliably crashed that way. Though if that's changed since 28.[12], they wouldn't have seen it yet, and there may be patches we should cherry-pick. > I understand, but don't you have some kind of centralized script or > group of scripts that runs the testing? In that case, you could make > the Emacs command, or its template, be part of those few scripts, and > then the change will be less painful. For us, this is about hundreds of upstream trees we don't directly control. How and where does magit invoke emacs during its build or during its tests? Or buttercup, or org, or bbdb, or emacspeak, or ivy, or lsp, or... How do we make sure we affect *all* of the invocations of emacs in all of those? Note here is just a subset things that Debian has packaged that might be affected (i.e. only the ones whose maintainers have decided to keep the Debian tree on salsa in the emacsen-team project): https://salsa.debian.org/emacsen-team > Yes, something like that. At least that's what we do in the Emacs's > own test suite (which, of course, is much smaller than yours). ...as long as "most" invocations are either "emacs" or respect say EMACS, this could work. I have no idea if that's true, but we do already know there are likely to be any number of places we'll have to fix. i.e. someone has told me that this approach will result in "a lot of bugs" (in the debian packages). They already know of places where "some of them try to choose which emacs to use, rather than just 'emacs'". We can handle that, but if we have to patch a lot of the upstream trees, that could be a good bit of work. That's certainly possible, but hopefully that helps give more context about why we were interested in some solution, among the possibilities, that's less potentially invasive. For what it's worth, we're also under a (not too close yet) deadline on the Debian side. We'd really like to have at least emacs 28 in the next stable release, and the first stage of the freeze is currently scheduled for I think January (though Emacs would I think be affected by a slightly later stage). For that to be possible, whatever we end up choosing here will need to be something we can finish accommodating across both the emacs package and all the add-ons by then. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4