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: Fri, 14 Oct 2022 16:17:56 -0500 Message-ID: <87v8omgl4r.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <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> <83v8om6x8u.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="16586"; 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 Fri Oct 14 23:18:49 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 1ojS4v-00046L-7e for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 23:18:49 +0200 Original-Received: from localhost ([::1]:33312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojS4u-0005vP-38 for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 17:18:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojS48-0005FL-L2 for emacs-devel@gnu.org; Fri, 14 Oct 2022 17:18:00 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37490) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojS46-0005Nj-AR; Fri, 14 Oct 2022 17:18:00 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id CCA31200F5; Fri, 14 Oct 2022 16:17:56 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 4DAC014E081; Fri, 14 Oct 2022 16:17:56 -0500 (CDT) In-Reply-To: <83v8om6x8u.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:297736 Archived-At: Eli Zaretskii writes: >> From: Rob Browning >> - 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. Hmm, which "this" did you mean? If you meant HOME=/does-not-exist, I thought people had already said that wouldn't work because the attempt to build trampolines would still cause a crash. But I may well have misunderstood. > 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. For what it's worth, the reason we'd been at least a bit inclined that direction is because if you have hundreds of emacs add-on packages (which I believe we do in Debian), and they all have build and or test suites that vary in any way they like, it could be much more difficult to track down all of the emacs invocations in each project's source to add some argument than it would be to just export an environment variable before running the suite. I suppose we could just shadow emacs in the path with a wrapper that includes the argument(s), assuming few of the projects have their own interfering options, and that they always use the same (or a handful of predictable) relative invocation of emacs, e.g. "emacs" not "/usr/bin/emacs" or... > 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. Right, though we also have to make sure we can do that sufficiently early in *every* case. > Thanks again for your comments and perseverance. Certainly, appreciate the help. -- 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