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, 01 Oct 2022 15:42:06 -0500 Message-ID: <87mtafnun5.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.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="36476"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 01 22:43:02 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 1oejK9-0009J1-Vg for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 22:43:01 +0200 Original-Received: from localhost ([::1]:49058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oejK8-0004C4-Se for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 16:43:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oejJK-0003O4-Qf for emacs-devel@gnu.org; Sat, 01 Oct 2022 16:42:11 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37446) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oejJI-0007Rs-Nk; Sat, 01 Oct 2022 16:42:09 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id A6F5D2013E; Sat, 1 Oct 2022 15:42:06 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 1CD7514E081; Sat, 1 Oct 2022 15:42:06 -0500 (CDT) In-Reply-To: <834jwnbi6c.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:296561 Archived-At: Eli Zaretskii writes: > You should know that the problems you needed to address with the *.elc > files don't exist with the *.eln files. The *.eln files have version > information of the Emacs to which they "belong" hard-coded into their > names. Right, I'd noticed that, and while I haven't fully understood the expectations/semantics yet, I'd started to assume much of what you've described. I also assumed we'd need to understand things even better before the Debian support is completely "ready" (right now we're working all this out in unstable). My current expectation is that if it ends up being feasible, we'll probably want to treat the package-related .eln files like the .elc files, and build them during the package install. For example, elpa-magit (the current magit add-on package) will want to generate both the .elc and .eln files for all of its .el files when its turn comes around during installs/upgrades. I say that because if it's a single-user machine and the user invokes "apt install elpa-magit", I'd imagine they're doing that because they want to use magit, in which case it doesn't hurt to get the work out of the way up-front, and it might help in that all the work will be finished at once, so they won't incur costs (battery-consumption, etc.) later, when they might not expect or want it. (Not a critical issue, possibly, but perhaps friendlier.) And if it's a multi-user machine, with a lot of emacs users, at the moment I don't see any reason to want to compile the same file 50 times for 50 users (or even more than just once), incurring the attendant power and storage costs. > Yes, by changing native-comp-eln-load-path you should be able to avoid > writing to the home directory of the user under whose credentials the > installation runs. If you need that. OK, thanks much. -- 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