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: Wed, 05 Oct 2022 22:04:17 +0300 Message-ID: <83ilkyrt1q.fsf@gnu.org> References: <87v8p01lbu.fsf@yahoo.com> <83lepwvzxq.fsf@gnu.org> <871qroyog9.fsf@yahoo.com> <837d1gvt35.fsf@gnu.org> <87sfk3yl10.fsf@yahoo.com> <87o7uqtlsl.fsf@yahoo.com> <878rlu48kq.fsf@gnus.org> <83r0zmrzcx.fsf@gnu.org> <83lepuruoo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17354"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 21:06:16 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 1og9ih-0004I5-Tv for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 21:06:16 +0200 Original-Received: from localhost ([::1]:47284 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og9ig-0003iB-DD for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 15:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og9gq-0002v1-WC for emacs-devel@gnu.org; Wed, 05 Oct 2022 15:04:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og9gq-0000io-AR; Wed, 05 Oct 2022 15:04:20 -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=ihPETuOX4nu1Tll4xcB1+cj9cLBvlKkFCMO5gYvhYf0=; b=JappsyCOI9A1 Fymj83owMzeeGJ+qwE7kxiVbJpdkI26SzEqU90dzFRf2g7QbwXkLrFiheVI2VskM2vk55YctXFRUh DmzY566Q3M/tx3vfB0Cse/4IHSnr4f4NrsD8oGCFDoMEAFdmQmH0gIaYXdh3XKoB6833FA91iuzGo 4sQ8JnSDRJ30j0FvjNj+4GTbvGXw7PNStW+RoTySo7AJyo2il1GSitjFHOg7rT1cD61mFSoVMAwlO d76AEpA72tmHYuRWKZtqpwKNpLa/erUXdGqknAxyzUnSu5ueCdHqbcgc2Ll8d/6hiwd/Vu71XpjhY BjxyZ/6PCzQAaa2sX+6mIw==; Original-Received: from [87.69.77.57] (port=4032 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 1og9go-0008CX-TG; Wed, 05 Oct 2022 15:04:19 -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:297007 Archived-At: > Date: Wed, 5 Oct 2022 20:56:00 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > > > Why would people want to have N files compiled, but not the N+1st > > > > file? How are the first N files different from the N+1st? > > > > > > Perhaps because 1500 <= N <= 2000 (or so) and the N+1st ist just one? > > > > Then it isn't the same N, is it? > > - Base .el(c)s pre-compiled. N. > - Additional .el (perhaps written by the user, perhaps > downloaded from Emacswiki or what not) (jit) compiled, > go to somewhere writable by the user (perhaps somewhere > under ~/.emacs.d). 1. Or 2. Then I ask again: why wouldn't the user want to have the addition .el compiled to .eln? > > > Perhaps because in the "normal case", the N+1st won't even happen? > > > > Why disable something that will never happen? > > ...in the normal case. The user should be still capable of tackling > the not-that-normal case. The not-that-normal case being user's own *.el files? Why wouldn't the user want to compile them into *.eln in that user's own eln-cache? Why would that user want to disable native-compilation instead? > > > I actually install a few packages from source, those I "personally" > > > care about (Emacs is among them), But I couldn't possibly do it for > > > the > 2000 currently installed on my system. > > > > What is "it" in "do it" above? > > Installing software from source. > > > And what does the 2000 number counts > > here? > > Debian packages: The Gnu compiler toolchain. The mail reader (mutt in my > case). A mail transfer agent (Exim). A Web browser. A web server. Lots > of different scripting languages. Networking stuff. SSH, rsync, git. > Qemu. Cross build tools. X and all those little helpers. R, Octave, I > don't know, all that stuff one needs to be happy :-) How is this relevant to the issue at hand? Only Emacs comes with *.eln files and can use them. Why are we talking about all the other packages? > > I don't see how disabling JIT compilation is needed for these 3 > > purposes. In particular, if all the *.eln files are already present, > > there will be no need to recompile them. > > I don't know exactly how the Debian packaging for Emacs proceeds, but > I think we are talking about two distinct situations here: > > (a) the binary install for the end user (for which the target is to > end up with (some, most) .eln files pre-compiled and typically > in /usr/lib or /usr/share, depending on whether those files are > architecture-dependent (I think they are) or not > > (b) the package build, which happens at the Debian developer's > box to build the Debian package to be installed to achieve > (a). > > The question is whether the pre-compiling of the .eln happens at > (a) (i.e. package install time) or at (b). It seems Rob has opted > for the first (perhaps because there are dependencies which have > to be resolved "late"?). > > Anyway, this "disabling of JIT" would be relevant for (b), if > at all (assuming I've been paying attention). For case (b) Rob said that the workspace is thrown away after the build, so whether the *.eln files are or aren't built there makes no difference. (And if the package build is done in batch mode, the async compilation is disabled there by default.) So, once again, I see no reason to disable JIT compilation for these use cases.