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: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 28 Jan 2023 19:09:45 +0200 Message-ID: <837cx6a8me.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7509"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 28 18:10:38 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 1pLoir-0001jj-TO for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Jan 2023 18:10:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLoiG-00035w-Q2; Sat, 28 Jan 2023 12:10:00 -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 1pLoiF-00035m-4r for emacs-devel@gnu.org; Sat, 28 Jan 2023 12:09:59 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLoiD-0004bx-Dz; Sat, 28 Jan 2023 12:09:57 -0500 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=zuZMeGJIcFpVDjqgfi7A7nfroXra6yDROFN0CVFE7Ws=; b=QXSaRxX2+dXW n62dfSXOfr/QguWVT2SozdK+F4rlnsIqNcwPZPWR3T1prE0pWuGe/6UVvf3wyYnWmz13J988xpko7 Cz7nkkQYkwZ6VaUHp66BvykQTKwytTKoLiU1HIbrVsnewkFb9G5H9zfxFU0JXvBpEDu2DipmQRDE3 gFS/ob22I59uhy5D+m663YdljFa6wOZb6biJ5s6hQHfLl2jxoO8AxjoZ3WANwftOR/6DYs1AXCF1Y 3ME5+WdGan8hfEeUxhXOQlQ5X5yVQKhFfzfRT4gZS6759LAI5lcsjH8tJ7EhOeuYE5NT8ImVAdQsw CBJeq/tvWaDXD7NSHAKCgw==; Original-Received: from [87.69.77.57] (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 1pLoiC-0008GZ-Tl; Sat, 28 Jan 2023 12:09:57 -0500 In-Reply-To: (message from Stefan Monnier on Sat, 28 Jan 2023 12:00:57 -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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302723 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org > Date: Sat, 28 Jan 2023 12:00:57 -0500 > > > 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? Sorry, I don't buy the "easier" argument. Distros are not users, they can do things even if they aren't "easy". > >> 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. Not from my POV, no. > 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. What do you mean by "alongside"? The code which needs trampolines is the code which advises primitives, and that is written in C. Where would "alongside" be in that case? > > 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. Smaller or not, most of it will be wasted in most sessions.