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: Sat, 28 Jan 2023 12:00:57 -0500 Message-ID: References: <837cx8cey0.fsf@gnu.org> <83357vauh5.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="4587"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 28 18:02:23 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 1pLoas-00010I-8E for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Jan 2023 18:02:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLoZr-0007eB-1H; Sat, 28 Jan 2023 12:01:19 -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 1pLoZl-0007WC-Gd for emacs-devel@gnu.org; Sat, 28 Jan 2023 12:01:17 -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 1pLoZh-0003Ga-Ea; Sat, 28 Jan 2023 12:01:12 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C00B3441034; Sat, 28 Jan 2023 12:01:06 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8F8AA44101B; Sat, 28 Jan 2023 12:01:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1674925264; bh=wLFsxicgMikU3b2N+623D+QrZKClznJMTkAVKnZ5GPw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bh5dEiKxDbJxkY5lEbZY4Hfy93DwwXtJYqolD/fTZtb9pJGA5iFPCRb2Z9oq6mVGu l+U7nw5CDYd42BKZCYAwWI8nowBnRm/JNzayq1mX5cr3v4Xpv1ubOI0ip3/jGokyfO /4sdrea0EjPALMaPY2fR1ISz6Er+Pm9mSX4Q9gs6uBbvrYo0PUqS+YUQTh5HPtwMK2 zqa63Gh8rpWlY4weVVAiFmczw4XWDmBLXVCHbtcmZ8aHZZQyP1RUDOFTxbbSCum7Zy yPcsMCTtCAwivwlCi0FMvgvHYmSaYktI5FysoiyH3KsUj+aQaYMx9ZQKx4mCpaBpNH iKf9SGt1KhedA== Original-Received: from pastel (unknown [45.72.216.69]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4BDB7121254; Sat, 28 Jan 2023 12:01:04 -0500 (EST) In-Reply-To: <83357vauh5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Jan 2023 11:17:42 +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:302722 Archived-At: > The Debian use case has other solutions, which don't require disabling > native-compilation. I never understood why they insisted on > disabling, instead of, say, redirecting the eln-cache to some suitable > place, whether a throwaway directory like /tmp or some other > directory. I hope maybe Rob will respond now and we could finally > understand why they want to disable the compilation, or they will > understand why disabling is not needed. Or maybe they do use the > redirect-eln-cache solution after all, and we just don't know? IIUC the problem is that they need to control this "higher up in the scripts" and have it take effect in many Emacs invocations underneath, so using an env-var (like $HOME) is an easier solution. Otherwise they may need to tweak many build scripts in many different packages. > In any case, inhibit-automatic-native-compilation, as implemented now, > doesn't actually disable compiling the trampolines, it just writes > them to /tmp. So if that is okay with Debian, why isn't it okay to > tweak native-comp-eln-load-path to do the same to begin with, I > wonder? Because one can be controlled via an env-var? >> 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). > That is already happening, and either native-comp-deferred-compilation > or inhibit-automatic-native-compilation will disable the following > async compilation. We had this through the entire Emacs 28 release AFAICT somewhere along the emacs-28 line, if your $HOME doesn't exist or the eln-cache is not writable, Emacs failed with an error at startup. I can't remember if we fixed this before or after Emacs-28.1. > cycle, and the only new issue that came up was with the trampolines > that are still being compiled and written to the eln-cache. Indeed, and at that point if the eln-cache is not writable then we fail, which is what still need(s|ed) to be fixed. >> 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). > > This have two problems: > > . it cleans up only on Posix platforms Yup. I hope it's "good enough" for our immediate needs, tho. > . it is fundamentally broken, since it doesn't actually prevent > native-compilation, so if the system cannot natively compile at > all (e.g., if Binutils are not available), this will still signal > errors Right, that's the more general issue of not being able to generate the trampolines, for which the only solution is to find a way to pregenerate the trampolines. We have not tried that hard enough yet, but I think it's too late to do that for Emacs-29. > The only solution we could come up with for the latter part is not to > compile trampolines at all, and it has another adverse effect: advices > for primitives will not work. Indeed, it's not a solution. >> 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. > Such a solution was proposed, but for some reason Debian didn't like > it, or at least that was my impression. My understanding is that we didn't get a clear answer. Until we have such a clear answer I'd assume that it *does* solve their problem. > And again, why should we only consider the Debian use case? AFAIK it's the only request we've had. All others were satisfied with `native-comp-deferred-compilation` (except for the fact that it's not sufficiently documented/discoverable, maybe). >> - 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). > > If we leave the compilation of trampolines to run time, we will > produce those same small files, right? No: what I'm suggesting is to pregenerate the trampolines before we know if we'll need them (a bit like `make trampolines`), but to place them alongside the code that might need it, so there's no additional "small" files containing nothing but a trampoline. Instead we add tiny chunks of code (the trampolines) to other `.eln` files and we do it at a time where we know we have GCC at hand. > And if you think about having a single .eln file with all the > trampolines, that is inefficient in another sense: we'd be wasting > memory by loading trampolines which are not actually needed. Actually, I don't know if that would be a problem: while the sum of the trampoline files is large, the concatenation of all the trampolines into a single `.eln` file should be *much* smaller. Stefan