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 21:32:17 +0300 Message-ID: <83sfk6yt3i.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <83h70m19yv.fsf@gnu.org> <87tu4mm7kt.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11886"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yandros@gmail.com, tomas@tuxteam.de, emacs-devel@gnu.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 20:33:52 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 1of3mi-0002ue-1Q for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 20:33:52 +0200 Original-Received: from localhost ([::1]:53786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of3mg-0002ul-WA for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 14:33:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of3lK-0000pt-8G for emacs-devel@gnu.org; Sun, 02 Oct 2022 14:32:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34200) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of3lJ-0006Kv-Nj; Sun, 02 Oct 2022 14:32:25 -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=7nrxrX9EXtMNLgmuAVHCAdivkaNlZIdEg+vveGTv+d8=; b=sT9Uyd/ByX9g RA8sHAiC5Dlvr37blPXnYku8yHdaMXVmguTt+jToNOUaUkpDwPqkuON/BU6FkapcoG1Zes18AquX0 HdaG3Jt4N4xflnet2JYOvyvB/5mjYyvI2fgdljSQ2KEmlahc1H7ATR3sdnvqX4hf9/PnxY/7xy9Rq sKeaTxbqaHyaXoEo4QbJMg4C2NLCwzd0MNXRc0/hCaZJXEY1mGsrU/BJxoAatzn1DpWUUHGEMSpb+ HTMvVaMeeNTbaVkOTvKew9nmocugHxld+zA4vA4bFOzI9tw3d15Jy22KWp5PuPujnFwkM5rH5ZsTE 9hWAor12Jn/JkVTZGj2wEQ==; Original-Received: from [87.69.77.57] (port=4260 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 1of3lJ-0005OF-6r; Sun, 02 Oct 2022 14:32:25 -0400 In-Reply-To: <87tu4mm7kt.fsf@trouble.defaultvalue.org> (message from Rob Browning on Sun, 02 Oct 2022 12:57:54 -0500) 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:296676 Archived-At: > From: Rob Browning > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Sun, 02 Oct 2022 12:57:54 -0500 > > Though note that for reasons we can elaborate on if desired, it might be > easier for us if the default for that variable could also be set via a > corresponding environment variable, but that's a separate question. > > (For example, we have relevant emacs-related packages where the upstream > build process runs emacs a level or two "down" (subprocess-wise), and > so it'd be a lot less invasive if we could just set an environment > variable to change the .eln destination, instead of having to figure > out how to change each invocation of emacs in that package (and > maintain those changes across future upstream versions). We could introduce such a variable, similarly to EMACSLOADPATH. But note several important considerations: . unlike with EMACSLOADPATH, the actual place where *.eln files will live is in a subdirectory of any directory in the list, due to the need of having them separately for different Emacs binaries and versions . EMACSLOADPATH is a mixed blessing: if you set it incorrectly, or forget that its value is inherited by subprocesses, you can completely hose an Emacs session, which is why we generally recommend against its use > A second, and a separable question, is whether Debian should try to > maintain system-level (root owned) .eln files the same way it does for > .elc files. > > I consider that an open question, and it could well be that the answer > ends up being "no". That's what we're trying to find out, and of course > we have to begin by trying to communicate why that might be desirable. Given the much more strict requirements for *.eln files wrt the target architecture, certain crucial aspects of the Emacs binary, and the contents and file name of the corresponding source file, my suggestion is to start from "no" and only consider "yes" if you discover good reasons through experience. E.g., my eln-cache directory has no less than 20 subdirectories, each one for a slightly different Emacs version and configuration. That might be somewhat extreme, given that I work on development of and use several versions in parallel, but I wouldn't be surprised to see several subdirectories for each of your users, and even less surprised to see different subdirectories for different users. So I think the case for common compiled Lisp files is much weaker for *.eln files than it is for *.elc files/ > It's certainly the case that if the consensus here (among the upstream > developers) is that we shouldn't do that, and that future > choices/changes aren't likely to take that use case into consideration, > then we have our answer. I only know that I didn't yet hear any good reason for rushing to natively-compile optional Lisp packages. That doesn't mean I'm dead certain there could be no such good reasons, of course, just that I'd like to see them described in enough detail to consider something different from what was envisioned during Emacs 28 development.