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: Mon, 03 Oct 2022 19:16:29 -0500 Message-ID: <875yh0l9ya.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <83h70m19yv.fsf@gnu.org> <87tu4mm7kt.fsf@trouble.defaultvalue.org> <87pmfa9k30.fsf@gnus.org> <83r0zqysyu.fsf@gnu.org> <877d1im5k3.fsf@trouble.defaultvalue.org> <83h70myrrp.fsf@gnu.org> <87r0zqknrx.fsf@trouble.defaultvalue.org> <83ill0yfct.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="29447"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, yandros@gmail.com, tomas@tuxteam.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 04 02:19:38 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 1ofVer-0007Y9-Rq for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Oct 2022 02:19:37 +0200 Original-Received: from localhost ([::1]:57334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofVeq-0006di-TY for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 20:19:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofVcO-00055O-BG for emacs-devel@gnu.org; Mon, 03 Oct 2022 20:17:04 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37484) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofVcM-0002rz-Cs; Mon, 03 Oct 2022 20:17:04 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 5A3E4201A0; Mon, 3 Oct 2022 19:16:30 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id F0E5614E081; Mon, 3 Oct 2022 19:16:29 -0500 (CDT) In-Reply-To: <83ill0yfct.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:296817 Archived-At: Eli Zaretskii writes: > [Full disclosure: evidently, none of what I write below matters, so > feel free to ignore.] Well, I can't speak for others, but it matters to me (your opinion and the other upstream developers'), or I wouldn't be here, and I'm very glad there's a "here for me to be" because I'm quite fond of Emacs :) > But okay, yes, if Debian users live under such severe restrictions, > then the case for having user-specific *.eln directories becomes > weaker. But I still don't see that it is weaker than disallowing > native compilation at run time. To be clear, I've never been talking about disallowing it for normal user use, and apologies if I made it sound that way. For normal users, if we pursued this, the idea would be that after "apt install emacs" finishes, they'd have a full set of .elc and .eln files corresponding to their version of Emacs, and the .el files they have. Then if anything changes in a way that warrants it, Emacs would (re)compile to their ~/.emacs.d/eln-cache/ as "normal". But for those who don't ever change their .el files (or shadow them), that would never happen, or would only happen for the files that they change/shadow. > And I guess now I'm confused what is it exactly that you'd want to > achieve. Do you want to disable native compilation, or do you want to > have all *.eln files in a shared location? Because it seems to me you > said you wanted both, and I don't see how both could be reconciled. The ability to disable .eln compilation entirely is only for some Debian-specific (though maybe useful for others) special cases, not anything we're proposing for "normal use". And it doesn't have to be "disabling" -- being able to redirect the .eln files to another (temp) dir would be fine too, as long as it wasn't too awkward to arrange for the entire (sub)process tree. Those special cases are (at least): - When building the relevant Debian packages -- for Emacs itself, for add-ons like elpa-magit, etc. Debian forbids package builds from writing outside of the package build directory /tmp, and another tree or two, e.g. HOME is not allowed. Note that this is normally handled by the Debian autobuilders, it's not something users typically do. - During package installs, i.e. whenever Emacs is run during an "apt install emacs" or "apt upgrade emacs", etc., and it may be run many times there, both directly, and indirectly as it rebuilds whichever packages need rebuilding (e.g. add-on packages). - During some autmated Debian tests. Hope this helps -- 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