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: The emacs-28 release branch has been created Date: Tue, 05 Oct 2021 14:29:59 +0300 Message-ID: <83v92b4slk.fsf@gnu.org> References: <83lf3dgbl3.fsf@gnu.org> <6c7a9f1a-bf2d-4213-b954-2025eee1f282@cornell.edu> <838rzaa264.fsf@gnu.org> <2434455f-34f5-3e6b-b26f-db7b66cf8f3d@cornell.edu> <83ee9287ef.fsf@gnu.org> <83a6jq84wu.fsf@gnu.org> <10401c4a-1d0a-817c-942e-f08ab3130552@cornell.edu> <834k9y814j.fsf@gnu.org> <83tuhx7w54.fsf@gnu.org> <30b78a17-2b95-5d0c-fb46-10c37ee91638@cornell.edu> <96912815-d275-8b54-9ba8-cc4fd5b0fe91@cornell.edu> <83v92c6f4n.fsf@gnu.org> <83sfxg6ehc.fsf@gnu.org> <83r1d06dry.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: kbrown@cornell.edu, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 05 13:32:16 2021 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 1mXigB-0006r6-5U for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Oct 2021 13:32:15 +0200 Original-Received: from localhost ([::1]:46082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXig9-0007eU-Vf for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Oct 2021 07:32:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35464) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXiej-0006Lu-Aa for emacs-devel@gnu.org; Tue, 05 Oct 2021 07:30:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33522) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXieg-0002yp-Kv; Tue, 05 Oct 2021 07:30:44 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1329 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXie9-00048P-T5; Tue, 05 Oct 2021 07:30:26 -0400 In-Reply-To: (message from Andrea Corallo on Mon, 04 Oct 2021 16:15:35 +0000) 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:276319 Archived-At: > From: Andrea Corallo > Cc: kbrown@cornell.edu, emacs-devel@gnu.org > Date: Mon, 04 Oct 2021 16:15:35 +0000 > > Okay I see what's the issue. In `comp-final' we spawn a child process > to run the final pass or not discriminating on the `byte+native-compile' > var. This is wrong cause this is not bound when using > `batch-native-compile'. Can you explain (or guess) why this caused the specific problem it did (i.e. truncation of some temporary file, AFAIU), and why only in that single .el file? Also, your fix introduces a new special variable for that, so I guess it means the problem is not specific to all batch native-compilations, only to some? If so, what is special in byte+native-compile and batch-native-compile that they require not to spawn a child process? Thanks.