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: Suppressing native compilation (short and long term) Date: Mon, 17 Oct 2022 20:07:57 +0300 Message-ID: <83o7ua1iqa.fsf@gnu.org> References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> <835ygob7ja.fsf@gnu.org> <834jw7a2ym.fsf@gnu.org> <87sfjp5t3d.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22481"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org, emacs-devel@gnu.org To: Liliana Marie Prikler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 17 19:09: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 1okTbo-0005cJ-G9 for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Oct 2022 19:09:00 +0200 Original-Received: from localhost ([::1]:60808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okTbn-0003NA-3b for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Oct 2022 13:08:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okTb1-0002ae-5X for emacs-devel@gnu.org; Mon, 17 Oct 2022 13:08:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60472) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okTb0-0006Ti-Gp; Mon, 17 Oct 2022 13:08:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=b9jyj1dRRk12xD7eKDWQEEfKkNqhpglhvgIgD6vx2a4=; b=h1YcxwhuTClXojBSG5Eo FxZhO+W5S0fpINXLNAlHDE1pcvcvUqRFOsKVBYtw1vGv3sJplGCaGD7oM/NVTe8KY2HyhB0IfWN+p 2cALmXkQcuHikDEyTcVCDsMbG/yEkGqx9Anh7G+5Q0RkwCqI0W8SEn+6IyhC5OrStAKcB4l60uBS1 RwQatWrmtmnKAjuI7jftOH3HdvvwpVEXg6PDkac1SgUzUd8Vpwl3BvrNDhzJ2uUQdQruB6P9PMsBB Ji6OdZfmf+cUcA8V8JCGiMVdbeDgKYcf/d+09kOGjc7jwly75HYNjQbMnEGXEfBypgN0kitoTWY2E JRKpkM2nKZyBAw==; Original-Received: from [87.69.77.57] (port=2599 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 1okTay-0001fm-NF; Mon, 17 Oct 2022 13:08:09 -0400 In-Reply-To: (message from Liliana Marie Prikler on Mon, 17 Oct 2022 18:59:11 +0200) 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:297969 Archived-At: > From: Liliana Marie Prikler > Cc: Lars Ingebrigtsen , Eli Zaretskii , > rlb@defaultvalue.org, emacs-devel@gnu.org > Date: Mon, 17 Oct 2022 18:59:11 +0200 > > > > > > I haven't followed the Guix part of this thread in detail, but > > > > > I thought I'd just note that Emacs 29 now has the > > > > > `inhibit-automatic-native-compilation' variable and and > > > > > `EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION' environment > > > > > variables, so this is implemented. > > > > > > > > I thought this change was just into master "for discussion", are > > > > we already suggesting users to integrate it in their > > > > infrastructures?  > > > > BTW AFAIU this usecase was already supported in 28 using > > > > `native-comp-deferred-compilation'. > > > The deferred-compilation switch still ends up writing to $HOME, > > > which the new inhibit one doesn't. > > > > I think Eli explained more than once how to avoid that also without > > using the new switch. > Now, I'm not following all branches of this discussion, so the chances > that I missed something are admittedly high, but the last time I > conversed with Eli about this, they said my use case was neither > supported nor something they'd consider supporting. Thus, I'd be > positively surprised to see it in fact supported. Which use case are you alluding to? Andrea refers to preventing writes to user's HOME directory. That case is supported (in more than one way), and doesn't need the new variable. AFAIU, the use case you were presenting was not about preventing writes to $HOME.