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: Sun, 02 Oct 2022 19:11:52 +0300 Message-ID: <83h70m19yv.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24048"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 18:13: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 1of1bB-00065s-DH for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 18:13:49 +0200 Original-Received: from localhost ([::1]:35118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of1bA-0003P1-5P for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 12:13:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of1ZS-0002h0-NP for emacs-devel@gnu.org; Sun, 02 Oct 2022 12:12:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of1ZR-0003Uy-WD; Sun, 02 Oct 2022 12:12:02 -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=3noG1+7EdYSLYIxrNmJE+kdZkKbIWM5/fDLwE9KCip0=; b=dhBwLvbU4GlJ 4yHUxHIE98a4SqQWBm+D8yClXzNgQhMf1pJbgY7PhJUFe0XYrk0ucXtsovx8jD8Sn7hNAs0XUJHne 6r6femCGFQPNyxjShlPOmVYW98paPDEM3nzaUkNAitr8/tiA622tZ2vooPwmslCIKBSz8uEeFtkDw NrP+XcbfXP2GsnOxCIDQ1tKpUxp0SOYpHDqK1Do1BZaxcigS2RYDp1xHrv5EcYMX5GhvvFmO5PCsz DjO/znbmpoFvirosbqgwjovPaWGDMhHGQ2ResBGx65KPOjm2ukE18KPz9oy/2DJa0jyQNek/hm0UW pPgvseN0Ouk5xPCKIDKd8w==; Original-Received: from [87.69.77.57] (port=3547 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 1of1ZQ-0006Jc-NQ; Sun, 02 Oct 2022 12:12:01 -0400 In-Reply-To: (tomas@tuxteam.de) 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:296633 Archived-At: > Date: Sun, 2 Oct 2022 17:53:46 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > The advantage of using JIT compilation is that this is how the > > upstream project meant it to be used, and this is how the defaults are > > set. Any deviation from the defaults should have a good reason, and I > > submit that such good reasons can only be based on actual usage, not > > on theoretical presumptions. My recommendation is to use the default > > JIT manner until and unless actual problems are reported by users. > > I see that, and this is the one view I mention above: the .eln are but > a JIT cache, and each user (or instance, if there are more than one > per user) has its own. Let me be blunt: this is currently _the_only_ view of the Emacs project. After a lot of deliberations, we didn't find any reasons for alternative views. My suggestion is to try our view before concluding that it doesn't fit some situations. > > Exactly. So what is the problem with directories writable by all > > users? > > User separation goes out of the window, and this is one important > service the OS provides. To illustrate, one user could put malicious > .eln files all other users would execute. This is about installation writing files into a shared space on disk, right? If so, this is something for the Debian packagers to figure out, because doing that is their request. And anyway, I don't understand how do *.eln files are different from *.elc files, which are already written to shared disk space upon installation. What am I missing? > > > That's all fine, but then users wouldn't profit from the pre-compiled > > > .eln. > > > > There's no profit, IME. There are only disadvantages: you are in > > effect fighting against the Emacs defaults, for reasons that are > > purely theoretical. > > I have the impression that some of that reasons are quite practical > for Debian packagers. I submit that those reasons were most probably derived from a broken analogy with the *.elc files and with byte-compilation in general. Not from actual usage experience. Native compilation looks deceptively similar to byte compilation, but it isn't. So if producing the *.eln files seems to contradict some Debian rules and procedures, my suggestion is to talk to the upstream project, before inventing solutions, because of 2 considerations: . the problems may not be real ones, only perceived ones . the upstream codebase might already provide solutions > > > In a Debian-distributed Emacs (caveat: I'm compiling my own one!) > > > there are .elc in /usr/share for all to use; due to the search path, > > > a user still can install her own in a directory writable by that > > > user and it will take precedence. > > > > > > Can you do the same for .elc? > > > > I guess you meant "with .eln files"? Yes, see > > native-comp-eln-load-path, which was already mentioned here several > > times. > > So that might be one part of the way out. If one needs it. I don't think they do, and I don't recommend going there.