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 20:56:00 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="THs3MlHYxeYiZPhv" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14204"; 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 20:57:40 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 1og9aN-0003WZ-IA for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 20:57:39 +0200 Original-Received: from localhost ([::1]:48416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og9aL-0001Li-P7 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 14:57:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og9Yw-0000c5-C5 for emacs-devel@gnu.org; Wed, 05 Oct 2022 14:56:10 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:45814) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og9Yr-0007Q9-LF; Wed, 05 Oct 2022 14:56:09 -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=131O16hyPPnutPQzG6dZeDAtFALv7v1ncE50zrGuJGM=; b=CpRmrbzCzahBmB7XxDaMFTpJuj fwqSjlQha728lBZyJtJStqVqeHSi/bU1khtuFdZKCuQh4XeXmjKB7hIrX3d2HhgWJ4y0uiCZXIQPw D3WHaKUhrGd7tMI+KJCoCIhH3oUy/hguT4YOLmehj2CODWa4rQO5reflvWLu/Nd7LM4k5CPze658l JkkHgZXcUJAMvorJhFAwRxFGdoIKo0jVZmprkrNDh/f8WA9Te+j03HSU+tcw24nIUcs3sVnM4uRQQ 4L6MaZJibXMHp/q/lVw0spd6XyXS4OB46JW44imBJVBUXxf0F6Bw6/+6sQhiqLwNz7dUDDsLxnYi8 hdpf+dWA==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1og9Ym-0004i9-3A; Wed, 05 Oct 2022 20:56:00 +0200 Content-Disposition: inline In-Reply-To: <83lepuruoo.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:297006 Archived-At: --THs3MlHYxeYiZPhv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 05, 2022 at 09:28:55PM +0300, Eli Zaretskii wrote: > > Date: Wed, 5 Oct 2022 19:59:38 +0200 > > From: > >=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 just on= e? >=20 > 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. > > Perhaps because in the "normal case", the N+1st won't even happen? >=20 > Why disable something that will never happen? =2E..in the normal case. The user should be still capable of tackling the not-that-normal case. > > The idea of a Debian package is to provide >=20 > I think the Debian case is not relevant, because they provide all the > *.eln files with the package you install (or so I understand). So > either the user will only use those packages where *.eln are already > provided (in which case there's no reason to disable anything), or > they will want to use packages outside of the Debian distribution, in > which case I'm asking why they would like to give up on compiling > those additional ones. It seems we are in violent agreement, then. Whatever the user installs "outside" the Debian packaging system is the user's business. It is desirable that it works well together with the Debian-provided baseline (and Debian tries to make that possible). > > 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. >=20 > 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 :-) > are you talking about 2000 Emacs Lisp packages that are not > bundled with the Emacs distribution and need to be installed > separately? Or are you counting some other kind of "packages"? No, Debian packages. > > As far as I understand, the wishes are: > >=20 > > (a) deliver a package with (all? as many as possible? most? .eln > > pre-compiled > > (b) build Emacs in a way that is idempotent (and doesn't change > > overall system state > > (c) perhaps run tests (possibly, ideally part of b) >=20 > 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). Cheers --=20 t --THs3MlHYxeYiZPhv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYz3TOQAKCRAFyCz1etHa RmFaAJ4zaKYvDqEd73QqNvCKDoYDCIxF4wCfeG6Y7ftyQPrvnW+FrD994BVTIUo= =bJ36 -----END PGP SIGNATURE----- --THs3MlHYxeYiZPhv--