From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Wed, 5 Oct 2022 21:40:07 +0200 Message-ID: References: <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> <83ilkyrt1q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k5kcGTBUxG58m//I" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3499"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 21:44: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 1ogAK3-0000jv-6o for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 21:44:51 +0200 Original-Received: from localhost ([::1]:58098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogAK2-0005RY-72 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 15:44:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogAFi-0000qh-3i for emacs-devel@gnu.org; Wed, 05 Oct 2022 15:40:25 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:55278) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogAFX-0000AT-QH; Wed, 05 Oct 2022 15:40:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qmfr7eI7R3Dy8SIralhurGwc3kt76ViggzYuMpVCDcs=; b=Ueg3OVVzy2Yw8StZf48RFEDHqk ZC7LhKZ9ibX6I7ksLbWQ4KlyRrR4hNpsKvk4QINr6wEJKCA6I9Iozy2pzLABy+OT8N1iUywZj55kh q9owc2MYTzQxgnHX56S+Z36EPMcXXMpHaaRGFpFVcNr06xo4hLuthKWsd/r5tf3d9iSo1ATYIpKxi 0CHEX9GFRi8zQ7FIOIzHnkNYb/zK7H2ZIp/nOK52qsHiH3k+P+AAy6Wvu5k2cw8hlRXzuM9bcMes2 PkTHO66olo0hPbnVPd0wwJBVWUbZhlgeHOyBU7PGLIfcIesBmP+9ueAm5idFGFuqxno8zV25ffnuR 8oJKnLtQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1ogAFT-0004vz-W8; Wed, 05 Oct 2022 21:40:08 +0200 Content-Disposition: inline In-Reply-To: <83ilkyrt1q.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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" Xref: news.gmane.io gmane.emacs.devel:297010 Archived-At: --k5kcGTBUxG58m//I Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 05, 2022 at 10:04:17PM +0300, Eli Zaretskii wrote: > > Date: Wed, 5 Oct 2022 20:56:00 +0200 > > From: tomas@tuxteam.de > > Cc: emacs-devel@gnu.org > >=20 > > > > > 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? > > > >=20 > > > > Perhaps because 1500 <=3D N <=3D 2000 (or so) and the N+1st ist jus= t one? > > >=20 > > > Then it isn't the same N, is it? > >=20 > > - 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. >=20 > Then I ask again: why wouldn't the user want to have the addition .el > compiled to .eln? I think nobody is proposing to prevent the user from doing that. > > > > Perhaps because in the "normal case", the N+1st won't even happen? > > >=20 > > > Why disable something that will never happen? > >=20 > > ...in the normal case. The user should be still capable of tackling > > the not-that-normal case. >=20 > 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? See above. This must be (part of) the misunderstanding. See above my text, perhaps it was unclear: "Additional .el [...] (jit) compiled go to somewhere writable by the user" We are in violent agreement here, I think. > > > > I actually install a few packages from source, those I "personally" > > > > care about [...] > 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? Just trying to explain how the Debian packaging works and what it is good for. Your questions seem to suggest that this is somewhat alien to you (but my impression might be wrong, too). > > > 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. [...] > 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.) As I understant, this might work well if it's possible to redirect/ restrict those target directories to specific places, yes. But Rob will know much better than I could. > So, once again, I see no reason to disable JIT compilation for these > use cases. Perhaps we can get away with it, yes. Cheers --=20 t --k5kcGTBUxG58m//I Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYz3dkAAKCRAFyCz1etHa RsA1AJ9J2L28r3OllbYfCaGsK8OT7tij2wCfY4zc91vQG8gR8RuYxOix8MMhkSQ= =CEZh -----END PGP SIGNATURE----- --k5kcGTBUxG58m//I--