From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Fri, 27 Jan 2023 18:57:20 -0500 Message-ID: References: <837cx8cey0.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="23157"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Andrea Corallo , Lars Ingebrigtsen , Rob Browning To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 28 00:58:34 2023 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 1pLYc6-0005mu-BD for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Jan 2023 00:58:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLYb7-0008Qb-3g; Fri, 27 Jan 2023 18:57:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLYb5-0008QD-2J for emacs-devel@gnu.org; Fri, 27 Jan 2023 18:57:31 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLYb1-00084b-BH; Fri, 27 Jan 2023 18:57:30 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3AF7C442DD5; Fri, 27 Jan 2023 18:57:23 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A7471442DD1; Fri, 27 Jan 2023 18:57:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1674863841; bh=vAD58h993F1Gl9ec3XYPzYflXknHYYaeBq7t934gssQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ChuKOS+9Z7ISfOK9jjECxeolRS3O9sEEvCVL2TIelGOvwBPnqt0Cw2+KDZnH3RlE/ pWAU2pdz7EKCvVyT6rt6Mf7RutuAVr17xQ2+nY72tbodX6ap56k2hxao1r6iC8sONH gZlTp1qOAR5UZuyfWxbaGMktucGZw7Zu2ubXkQoIZ3Y4SCugk4RsD7Dg6nWSC8Rp71 Ob37JM3to02Fqs8jxq1e1FyxmPVDAe9KsLmBPOUCAZA3MczIf1bD52qSVxo7Zp+mHq kFeZjnxA22OE8Z5fL8E+PhHDnCprBOLJClwWTPqguDP1lSb53FBndFU+FR6pWfQZSf gNyAyE44tg8PA== Original-Received: from pastel (unknown [45.72.216.69]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B6D312250A; Fri, 27 Jan 2023 18:57:21 -0500 (EST) In-Reply-To: <837cx8cey0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Jan 2023 14:57:59 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302693 Archived-At: > Please respond soon, so as not to delay the pretest of Emacs 29. AFAICT the main issue is how to handle the case where the home directory is not writable (or doesn't exist). I think the Debian packaging needs mostly stem from this. For "normal" compilation, we should just make sure that in the absence of a writable eln cache Emacs still behaves correctly, i.e. it should just load the `.elc` file and move on (without native-compiling it). For trampolines, in the short term we should probably add a fallback to use an eln-cache in the `temporary-file-directory` (i.e. use the code we currently use when `inhibit-automatic-native-compilation` is non-nil). I think together this should let Debian get the behavior they want, by setting HOME to /doesntexist. And that should make both `inhibit-automatic-native-compilation` and `EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION` unnecessary. There are still some problems after that: - HOME is ignored when the user is root (Emacs uses something like ~root/ or ~$LOGNAME/ instead). I think we should throw away this (mis)feature, but I understand some people like it when they use `su`. Maybe a workaround is to tweak that (mis)feature so HOME is only ignored if it points a directory that belongs to another user, or so HOME is not ignored when it points nowhere. - There's of course the problem of needing to compile trampolines when GCC is absent. The current `make trampolines` kind of solves that, but it's ridiculously inefficient (the code for the trampolines is trivially small, compared to the size of the generated `.eln` trampoline files). Maybe a better solution is to precompile the trampoline when we generate a `.eln` that may need a trampoline, so that the (small) trampoline code is directly included in the normal `.eln` file. Stefan