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 09:42:04 +0300 Message-ID: <83edvqafr7.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7101"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 08:43:05 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 1oesgr-0001fx-0E for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 08:43:05 +0200 Original-Received: from localhost ([::1]:46628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oesgp-000863-Ga for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 02:43:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oesg4-0007Qo-16 for emacs-devel@gnu.org; Sun, 02 Oct 2022 02:42:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39868) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oesg3-0007Sv-9h; Sun, 02 Oct 2022 02:42:15 -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=GBc4Awy7whVyHCvyiz95YtANFPJs7LEs8cFCE9Q/xKo=; b=qNuom/JREEd3 PZbiWi1HEbkrwACWrYOL+HmFu4j0sPk3SoVOuQFk0rjfkMQHV0FYSNLuT8Ny38asj3xBZ+4utblox r69lpn2o7bCWcgEmeppexZMHaihasvYjyxWAD5IZRToIdg6XoONrEpE98wkqrZzlXZGf26WxBT0Z0 DX+Ljc8HgUK+FCghPT1ndotOU+FkCxMVNnUneUzDSuWg44Ai6WdezM+/UQf5ODsZ1xK9e1Qzs6Z1O Z2VKsR/1Zxuf/Opqj+VamxUe3Yy02etkX6Coq8GPsKHus06PoctRQVDLeCtSjw5M5Fq2huQK69VMZ M/T1LTevjqBtX3bMTexWfw==; Original-Received: from [87.69.77.57] (port=2239 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 1oesg0-0001X3-Sy; Sun, 02 Oct 2022 02:42:13 -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:296584 Archived-At: > Date: Sun, 2 Oct 2022 07:58:33 +0200 > From: > > I see there two views: the distributor's (represented here by David's) > and the jit's (Eli). For Eli, the file system objects are just a long > term cache of the jit's work (longer than one Emacs session), for > David, since the package's .el (and possibly .elc) are immutable (and > of course, the whole Emacs runtime), the corresponding .eln can well > be built at package install time. That would avoid each user to have > an identical copy of them As explained in my other message, I see no reason to make such assumptions. There's no reason to believe that a user who installs a package will immediately start using it. And even it they do, why should we care about some extra disk space or identical files being present? disk space is cheap, while the flexibility this allows (like each user can have a slightly differently-configured Emacs) is non-negligible. > (and of course, the initial wait). There's no wait: a package can be used immediately after loading or requiring it. The replacement of a byte-compiled by natively-compiled code happens transparently and doesn't affect usage nor causes any waits. 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. > That does make a lot of sense in a multi-user system Not to me, it doesn't. It makes _some_ sense, but there are other considerations. > > The other part of what I asked is that if for some reason installation > > does need to compile files (something that I still need to understand > > why it happens), there's nothing that hard-codes HOME in the directory > > list used for that. You can set native-comp-eln-load-path to anything > > you want, and only the directories in that list will be used. > > Yes, but. It's not about HOME, but about a user-writable space. A shared > space for .eln would have to be writable by all users if the compilation > is to succeed when invoked on behalf of each one. This is a no-no under > a multiuser system. ??? What "user-writable space"? If we are talking about install-time compilation, then the *.eln files should be deposited in some centralized place to which the installation process can write. And if we are talking about JIT compilation when the user runs Emacs, then the home directory is perfectly appropriate, and is writable. No one suggested that JIT compilations from "normal" user session should write to shared directories (and if someone did suggest that, IMO this suggestion makes no sense). So I think you confused these two possibilities, because the problem you raise doesn't exist. > Install is invoked as root, so it can put the results of its compilation > to a place readable by /all/ users (typically some /usr/share or /usr/lib, > depending on whether the results are architecture-independent). Exactly. So what is the problem with directories writable by all users? > > Emacs doesn't require a writable HOME, it requires a writable > > directory to store *.eln files. It doesn't have to be HOME. And once > > again, I still don't understand why *.eln files are produced at > > installation time in the first place. > > 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. > 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.