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: Fri, 14 Oct 2022 22:06:25 +0300 Message-ID: <83v8om6x8u.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18030"; 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: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 14 21:09:22 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 1ojQ3d-0004Ua-Sy for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 21:09:22 +0200 Original-Received: from localhost ([::1]:49374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojQ3c-0007My-4V for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 15:09:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojQ1n-0006eP-KE for emacs-devel@gnu.org; Fri, 14 Oct 2022 15:07:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33564) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojQ1m-0004H6-Hw; Fri, 14 Oct 2022 15:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=r6yf9EEaIBckm63AXb4LgAGDdNZ4uqEOR/LwD6h3Af4=; b=hJ/TweAF6A9C Q76ivYjBW91A9sv7fGt2yN9wsvG8t9JUc7ALBl75j4PzCi6kgyGxBIGG3iil1TRtrVEgeD79XDn6Q UPmXws+t+CawOFkWmnlLcuP7hR2IQiDUlWIMii+dJSrFGzCZ654nPPRC/In4bLvn0hd+FCTGLGdQW 47zHsOlEORhjpHAyx33vylVuIGpCckRTztBCcpydbX5dnZ9t5MmzlshNy4WB6UKzZwj9UShaOp+Em YbuOdoM4NIvrfiYFwT1gz6zDGozydx6pO++787nmnR3rwikadDUuv/vSQi/oBctp8EVgwIQyoqtQs ln0zuXnjV8wzUvCALztvVg==; Original-Received: from [87.69.77.57] (port=3630 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 1ojQ1D-0001JS-Ui; Fri, 14 Oct 2022 15:07:06 -0400 In-Reply-To: <87fsfqi95f.fsf@trouble.defaultvalue.org> (message from Rob Browning on Fri, 14 Oct 2022 12:53:48 -0500) 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:297730 Archived-At: > From: Rob Browning > Cc: larsi@gnus.org, akrl@sdf.org, monnier@iro.umontreal.ca, > david@tethera.net, emacs-devel@gnu.org > Date: Fri, 14 Oct 2022 12:53:48 -0500 > > Eli Zaretskii writes: > > > I'm still discussing with Rob his needs. I hope to eventually > > understand their needs. For now my only conclusion is that they need > > to tweak native-comp-eln-load-path in some situations, to control > > where the *.eln files are deposited. Which is easy and supported > > already, AFAIU. > > Eli, Lars, Andrea, and others, I think I'm mostly caught back up with > this thread, and hope to summarize a few things here: Thank you for your summary. > - We'd prefer to still be able to set HOME=/does-not-exist, which I > assume would mean that we'd need some other way to redirect *all* of > the eln file writes (including trampolines). > > Our practice of setting HOME to a nonexistent directory during some > packaging operations allows us to detect unexpected, and erroneous > attempts to write to HOME during those processes. This should work for preventing the native-compilation from storing the *.eln files. If it doesn't work for you, please tell the details, and we will investigate. > - If we are going to have "some other way" to redirect the eln files, > then for us an environment variable might be easier, so that we can > just export it before we start the relevant build/test/etc. and then > it'll affect all invocations of emacs in that environment. I > suspect an environment variable might also make it easier to > establish the setting "early enough" in the emacs startup process, > but don't know that. One other way is to change the value of native-comp-eln-load-path. I hesitate to add an environment variable for that, because environment variables are inherited to subprocesses, and so setting a variable for some Emacs process will affect all of its Emacs subprocesses. This was found to be a reason of tricky and hard-to-debug problems when users set EMACSLOADPATH like that, and I presume the same can easily happen with the equivalent variable for *.eln files. So I'd rather not add such a variable unless we find a very good reason. > - As an aside, I suspect Emacs may eventually want to have some way to > restore the ability to tolerate an unwritable filesystem. With respect to writing the *.eln files, Emacs will look along native-comp-eln-load-path for the first directory that is writable, and use that. So you could at least partially handle this case by making sure native-comp-eln-load-path includes at least one writable directory. > I'd much rather use emacs there, than /usr/bin/sensible-editor. Of > course now I know that I could just set HOME=/tmp and proceed, but > will others? I've now documented this method in the ELisp reference manual, in the hope that it will make this more discoverable. Thanks again for your comments and perseverance.