From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 13:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78783@debbugs.gnu.org Cc: Andrea Corallo , app-emacs-dev@janestreet.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17498216744609 (code B ref -1); Fri, 13 Jun 2025 13:35:02 +0000 Received: (at submit) by debbugs.gnu.org; 13 Jun 2025 13:34:34 +0000 Received: from localhost ([127.0.0.1]:44991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ4YE-0001CG-3O for submit@debbugs.gnu.org; Fri, 13 Jun 2025 09:34:34 -0400 Received: from lists.gnu.org ([2001:470:142::17]:50454) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ4YA-0001By-8i for submit@debbugs.gnu.org; Fri, 13 Jun 2025 09:34:31 -0400 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 1uQ4Xy-0007Ge-Al for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2025 09:34:20 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uQ4Xv-0005EV-82 for bug-gnu-emacs@gnu.org; Fri, 13 Jun 2025 09:34:18 -0400 From: Spencer Baugh Date: Fri, 13 Jun 2025 09:34:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1749821650; bh=SGDJaMZ9Q2BDUlaSHVI154lz2QZlxhXTh2g4tnwxvmM=; h=From:To:Cc:Subject:Date; b=DqG4ka9r0A51NFYRVyjzKBZWHIYsDQhguRoXMqx8IEOHgXMI99XJ54QjX+S9FwvSr 4PkoMjZ1FWSWE722QgpfivcHiaca/yYyTFPztRCmSixRN6+yAjmgN3s6ziE5unCtmT MrmjzQUTVZtuxsb/cjEgkcsoZw/VGN2Pw7hTCAi2BymvJOyCGW3Sq7XTFygIVSTfQV XveOzR9ERy8VqHE3bS6YILP+80b7yYLQLUI2nAnY1r4hPwvdmBx7enoPWpRWp+AEx3 mgljw+ioizx4enqegmNSOHaFHieflGa1vCrGAZmLQiKk/kemAM0VAq5cR/VJ8hYgVQ kmreaEzgpCgNA== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Native compilation of site-lisp directories during the Emacs build (e.g. --with-native-compilation=aot) produces .eln files which are unused when installed. The reason is that the absolute file name of the site-lisp directory differs between build-time and install-time, and therefore comp-el-to-eln-rel-filename computes a different path hash for the files contained in site-lisp at build-time and at install-time. The same issue would affect AOT native compilation of all Lisp in Emacs, except that there's a workaround built into comp-el-to-eln-rel-filename, as explained by this comment: As installing .eln files compiled during the build changes their absolute path we need an hashing mechanism that is not sensitive to that. For this we replace if match PATH_DUMPLOADSEARCH or *PATH_REL_LOADSEARCH with '//' before computing the hash. In other words, file names containing e.g. "30.1.50/lisp", like "/usr/local/share/emacs/30.1.50/lisp/foo.el", are transformed to "//foo.el" before the path hash is computed. I suggest the same should be done for file names containing "30.1.50/site-lisp". That would resolve the problem and allow site-lisp to actually be AOT-compiled. In GNU Emacs 30.1.50 (build 19, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2025-05-26 built on igm-qws-u22796a Repository revision: 1743ab3d48bedae367ca6a1deb3faf8f902e7d5c Repository branch: emacs-30 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-tree-sitter --with-native-compilation=aot PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.174982674528748 (code B ref 78783); Fri, 13 Jun 2025 15:00:02 +0000 Received: (at 78783) by debbugs.gnu.org; 13 Jun 2025 14:59:05 +0000 Received: from localhost ([127.0.0.1]:47760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5s1-0007Tc-7B for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:59:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56572) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5rz-0007T5-HP; Fri, 13 Jun 2025 10:59:03 -0400 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 1uQ5rt-0008KM-GH; Fri, 13 Jun 2025 10:58:57 -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=XRDycKBFCb3YiZfanwX7Ox3SHysFa61EduojfUqNHEA=; b=eNvHesizoqRx 8rJPCOT99xOTVuRCp3nkIW9N1N6SM/S0dW2lSwC+eUcHQqPLAXQqVPvAT4PjlSS/ALkz5s2itwCi5 QqJlPnECYCn1DFbEpuPVDHmxPgQdmm94BU29DAWDIANT+o4BlU8/Xya9PMrAeS+cMNNwr3493+WoR Evp81dkttQXjIGf09kYmuUCJKzXuwDvhG/t8BYbssdyAAEGR4y66gm9r2ZxyQ/nVnTv4c5zNjfkHA sYLxICigcXH7sr2rGGiWIpPOWh42U9NelxCD9giNdSAMF3DJCtBcWsqRtoCOmGcUxiQOFE4ceZ5sL 7rT2zRqz4Q0P1svqQPIfRw==; Date: Fri, 13 Jun 2025 17:58:54 +0300 Message-Id: <867c1felht.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) severity 78783 wishlist thanks > Cc: Andrea Corallo , app-emacs-dev@janestreet.com > Date: Fri, 13 Jun 2025 09:34:10 -0400 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > Native compilation of site-lisp directories during the Emacs build > (e.g. --with-native-compilation=aot) produces .eln files which are > unused when installed. Why are you compiling files in site-lisp during the build? This is not supported, and I see no reason why we should extend our build processes to support it. Why cannot you compile site-lisp files after Emacs is built and installed? From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:42:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.174982931327881 (code B ref 78783); Fri, 13 Jun 2025 15:42:04 +0000 Received: (at 78783) by debbugs.gnu.org; 13 Jun 2025 15:41:53 +0000 Received: from localhost ([127.0.0.1]:48492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6XK-0007F4-OU for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:41:50 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43001) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6X6-0007CS-TP for 78783@debbugs.gnu.org; Fri, 13 Jun 2025 11:41:41 -0400 From: Spencer Baugh In-Reply-To: <867c1felht.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 13 Jun 2025 17:58:54 +0300") References: <867c1felht.fsf@gnu.org> Date: Fri, 13 Jun 2025 11:41:27 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1749829287; bh=mvysvRWONlyiZ4QX0p2VP5wvXcvBOzsK2LvW9lwe0bI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=r/l6vEqcrUJY2wPiG8WGu/rDGwonJREfvxMuDJo7fxw7ssBMYXIAw7jbpB3ZFaiys egzpo1Krb+MfDq7LCqvkIsHMrl80ltjQdQNTWS/Up3e25eVahhjkyJjh8X4+zlQXWy yS65x3FyRjD+NIU1UIDOVkOgX8gh48L9Ej4Kfj0xx3wj2GLfi7DtGBHnSq7axMeTQ9 FqVxGHHXXvAU96NZ27cEoZa7RSCjmUINu//YojQPdiUb5ze2tHeje8dpuIK4c6wwLU 9KEMBIgJbZw9QC2uMAgiBQDAkdUp7h4v8l3qh2SsI1pHriewwte8MCgbZwHm4KnPNZ nBZoMmUy0JkXA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > severity 78783 wishlist > thanks > >> Cc: Andrea Corallo , app-emacs-dev@janestreet.com >> Date: Fri, 13 Jun 2025 09:34:10 -0400 >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> >> Native compilation of site-lisp directories during the Emacs build >> (e.g. --with-native-compilation=aot) produces .eln files which are >> unused when installed. > > Why are you compiling files in site-lisp during the build? This is > not supported, and I see no reason why we should extend our build > processes to support it. > > Why cannot you compile site-lisp files after Emacs is built and > installed? If a site-lisp file is built (whether as part of Emacs or not) and subsequently installed into the site-lisp directory, its file name will change. That changes the path_hash computed by comp-el-to-eln-rel-filename which will cause this issue. This is a general problem with AOT-compiling files which are subsequently installed somewhere else. It applies both for core Emacs files and for site-lisp. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.17498365272015 (code B ref 78783); Fri, 13 Jun 2025 17:43:02 +0000 Received: (at 78783) by debbugs.gnu.org; 13 Jun 2025 17:42:07 +0000 Received: from localhost ([127.0.0.1]:49239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8Pn-0000WQ-5j for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:42:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8Pl-0000Vs-6c for 78783@debbugs.gnu.org; Fri, 13 Jun 2025 13:42:05 -0400 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 1uQ8Pe-0005UE-4f; Fri, 13 Jun 2025 13:41:59 -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=3zAExQrQaogerxoMLBvL8sPS/7FgaEL80n1aI2KIYSE=; b=Tta6rDaO3o7j J7uM/hD2OjiqmBOEcHwGMy4NI/j8r0N4MgeRy5D4YlGjjQrL+Mxte15dJxMAKPw3Hg2U/JueQOvJj 6h/LZSk6o/kb3vudfXH7RjrBDZJ6zVrEV7GAtdAO6r1c/NyAOb88yMwyUwBmE3owRKWeMUthNhPLL 1poGiVNGSFPIqcQr+w+e1xZoqgBDvL+8q8WZmiL06ksjX54HsvV/hCZM0WZJF5+C2L/ZAuAN273F+ vGodQDLORBk0Nykk4nZ13OhKGgPSiInUf7ej+SKW2tel418LDzFpABr+LXnPSgAMAA5qW8kxnT/3w 1M8va/ez5UTI/vCgxHPYKQ==; Date: Fri, 13 Jun 2025 20:41:55 +0300 Message-Id: <86h60jtu70.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Fri, 13 Jun 2025 11:41:27 -0400) References: <867c1felht.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com > Date: Fri, 13 Jun 2025 11:41:27 -0400 > > Eli Zaretskii writes: > > severity 78783 wishlist > > thanks > > > >> Cc: Andrea Corallo , app-emacs-dev@janestreet.com > >> Date: Fri, 13 Jun 2025 09:34:10 -0400 > >> From: Spencer Baugh via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" > >> > >> > >> Native compilation of site-lisp directories during the Emacs build > >> (e.g. --with-native-compilation=aot) produces .eln files which are > >> unused when installed. > > > > Why are you compiling files in site-lisp during the build? This is > > not supported, and I see no reason why we should extend our build > > processes to support it. > > > > Why cannot you compile site-lisp files after Emacs is built and > > installed? > > If a site-lisp file is built (whether as part of Emacs or not) and > subsequently installed into the site-lisp directory, its file name will > change. That changes the path_hash computed by > comp-el-to-eln-rel-filename which will cause this issue. > > This is a general problem with AOT-compiling files which are > subsequently installed somewhere else. It applies both for core Emacs > files and for site-lisp. No, core Emacs files are okay and supported. It's compiling site-lisp files in this way is not supported. And you still haven't answered my question: why do you need that? The supported way of compiling site-lisp files is after they are installed in site-lisp. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Jul 2025 18:52:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175200067823860 (code B ref 78783); Tue, 08 Jul 2025 18:52:03 +0000 Received: (at 78783) by debbugs.gnu.org; 8 Jul 2025 18:51:18 +0000 Received: from localhost ([127.0.0.1]:44813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZDPQ-0006Ca-GS for submit@debbugs.gnu.org; Tue, 08 Jul 2025 14:51:18 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43109) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZD0B-000433-Bw for 78783@debbugs.gnu.org; Tue, 08 Jul 2025 14:25:12 -0400 From: Spencer Baugh In-Reply-To: <86h60jtu70.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 13 Jun 2025 20:41:55 +0300") References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> Date: Tue, 08 Jul 2025 14:25:03 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1751999103; bh=sXnP1skkmb4H/2AhGWtZQjvDoEQCaCg3b82WsrQcJw0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=aCEpjGDUZZpFqQT79KSH/vGet1qcb2IMG8Osr5QnnVQaGi1+mbvXRo2rAhL12ZfLp /WkzC7FvJdggSR2NEi1WIm2S9oShLnkpEDnAOdOH6GDCePfLY7bqy3xBt+LOIgH0sI lk5gJjQflZOMBUHV6ycPuxjhYmfAZF4uG4LvJiTNgQS8Y6Je/4L+md+E+D3/T9yAs4 FPcejoVSDGmpR4ticj7vss7XHAMT+KVG7P81rwZL90Sk/uqU25NMfJW01GzdGeptgE /uLT5ytMsT+VJbirz4IVAslArolNpKji5DpBPTNiTtZm/ymls5tQ2rPt+mQ0cbigXn BAvfPJwDUDp4Q== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com >> Date: Fri, 13 Jun 2025 11:41:27 -0400 >> >> Eli Zaretskii writes: >> > severity 78783 wishlist >> > thanks >> > >> >> Cc: Andrea Corallo , app-emacs-dev@janestreet.com >> >> Date: Fri, 13 Jun 2025 09:34:10 -0400 >> >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> >> the Swiss army knife of text editors" >> >> >> >> >> >> Native compilation of site-lisp directories during the Emacs build >> >> (e.g. --with-native-compilation=aot) produces .eln files which are >> >> unused when installed. >> > >> > Why are you compiling files in site-lisp during the build? This is >> > not supported, and I see no reason why we should extend our build >> > processes to support it. >> > >> > Why cannot you compile site-lisp files after Emacs is built and >> > installed? >> >> If a site-lisp file is built (whether as part of Emacs or not) and >> subsequently installed into the site-lisp directory, its file name will >> change. That changes the path_hash computed by >> comp-el-to-eln-rel-filename which will cause this issue. >> >> This is a general problem with AOT-compiling files which are >> subsequently installed somewhere else. It applies both for core Emacs >> files and for site-lisp. > > No, core Emacs files are okay and supported. > > It's compiling site-lisp files in this way is not supported. And you > still haven't answered my question: why do you need that? > > The supported way of compiling site-lisp files is after they are > installed in site-lisp. This makes it difficult to develop code that will be installed in site-lisp, because code which is not installed cannot be tested with the native-compilation that will be used when that code is actually installed. Since there are sometimes bugs in packages when used with native compilation, it would be better to be able to run the code before it is installed with the same native-compilation artifacts that will be used when it is installed. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 12:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175206251815103 (code B ref 78783); Wed, 09 Jul 2025 12:02:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 12:01:58 +0000 Received: from localhost ([127.0.0.1]:49383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZTUs-0003vX-Bc for submit@debbugs.gnu.org; Wed, 09 Jul 2025 08:01:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60524) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZTUp-0003uv-Eo for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 08:01:56 -0400 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 1uZTUi-000092-ST; Wed, 09 Jul 2025 08:01:49 -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=sfAbC88fIjzXxdHA8XYqQ2aoZCcIcNGVqJHYXc6HYQg=; b=HceuGBpfloTk JMk8F5UHDOtAAhqAyPsnW87DIeNAMWF/gMtwC5thHFJy5QvrLX5CgTdIJuwAZon23k/p00+iEHhq9 460zSyXdUiWegj98jeuaUAnm4+6Tj6VLiDzZP3MQn0tLRpPdDzA0tJu2HLiIn5fg+azTEo41Ha4dk gJLxXaqqCdpKWpqefqOiRsCQoWJLLel2hHcvrhM38JtswveaIuYANOExmCeF8YzGndp4H7mUKP4YU aNmqI1vHuZz7gDNL8aGDUONJDokbBLqzjcq0/4Vsc4ZlN3EVafk9rUsK7Q2ynVI1lZKqz7dFHKpsU Hs8ZDGlXPG91WVGiJAiI0g==; Date: Wed, 09 Jul 2025 15:01:44 +0300 Message-Id: <86tt3lindj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 08 Jul 2025 14:25:03 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com > Date: Tue, 08 Jul 2025 14:25:03 -0400 > > Eli Zaretskii writes: > >> This is a general problem with AOT-compiling files which are > >> subsequently installed somewhere else. It applies both for core Emacs > >> files and for site-lisp. > > > > No, core Emacs files are okay and supported. > > > > It's compiling site-lisp files in this way is not supported. And you > > still haven't answered my question: why do you need that? > > > > The supported way of compiling site-lisp files is after they are > > installed in site-lisp. > > This makes it difficult to develop code that will be installed in > site-lisp, because code which is not installed cannot be tested with the > native-compilation that will be used when that code is actually > installed. Since there are sometimes bugs in packages when used with > native compilation, it would be better to be able to run the code before > it is installed with the same native-compilation artifacts that will be > used when it is installed. Emacs 30 and later has the emacs-lisp-native-compile command, which can be used to compile the file visited in the current buffer. The companion command emacs-lisp-native-compile-and-load will also load the resulting .eln file. I think these two commands can be used to test the results of natively-compiling any Lisp file, anywhere. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.17520670837047 (code B ref 78783); Wed, 09 Jul 2025 13:19:01 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 13:18:03 +0000 Received: from localhost ([127.0.0.1]:49675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZUgU-0001pb-DT for submit@debbugs.gnu.org; Wed, 09 Jul 2025 09:18:02 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:47475) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZUgR-0001oh-DM for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 09:18:00 -0400 Received: from mail-ej1-f72.google.com ([209.85.218.72]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uZUgL-00000009FyL-3NdC for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 09:17:53 -0400 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-ae0ba0eb825so366553366b.1 for <78783@debbugs.gnu.org>; Wed, 09 Jul 2025 06:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752067073; x=1752671873; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GuEYfZgv7awb/btA96e5UuAq1dFc+d93vAzTc3dNfJo=; b=YzmrWJIzjta98ageih/SQEOmeFJKyM9lhL0tmpYQiJ0Iz8T7sh9lEIXehDZJm8pM45 xlcXGr2Um3JvCC+Y9j6AD4CTV49KRnZSl7kvcPG+hGDc+i+JwqeAf/9m9fjWZJhcqgoU Y3By3OVax+s/8QU/FH2O3CXCb0L8FU6650Hi0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752067073; bh=GuEYfZgv7awb/btA96e5UuAq1dFc+d93vAzTc3dNfJo=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=obiP9jv4mCxozgkUfsz6/MlV65a0udsf2QK1CW5FqO31yEJTJlCcNlxtF2Zxsmd0Q 4qerbFDFj5qjKFJdDvrU4daxGVb88s4T46dz9cZNXvocvpwkce9ftoJob+l2oq8v26 Y2w6g/ynXSySWayyD7ZYe//kEaSZzT0Ww7dctmbRvGToitbax0Qa07a7gf5Re8++ZO z1xDpt1Brh+xTWyuNdvnKo1hRBiQ9IS72bj4wgh64JWHidryFFJxWI3SHd0SpPBmLx GUUPDGKdadL35sR5jmI3lDv7S5Bua9Aq+GzSSEkgTdRE+Bq0RCTVlD4Jgd+BhXUvtm d457c4pB2Varw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752067073; x=1752671873; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GuEYfZgv7awb/btA96e5UuAq1dFc+d93vAzTc3dNfJo=; b=scDSkhqyO2v6DcKX4by4p5Sl5X5m9hjY4rrIQLXsG2s/yGxz2mu5xvKHd7YTIRU/0x gpZoX0PJYs90SEcwt62MI3D0VM0A5dwoXDqYaKtOTN9yVgrAPpgIPkzrTKCxWWRvU+jP zpSwf/R5Wu4/EnRvN86B5ZyLksYyb8c2Dh9WHvWdM+bZQ6wh/loCtaj5mZKy979ukDQ+ aZxeUsOtJNKix/yiUQNiabof/Vp5m55dZ1f7YcPxP0DaFzvMuJPlhSklyWWxGjUxCFvr x8+CXyBr9V5gZz5GRUZ3UOJTqFHhUpK/ux+rhC67b6EsDKM0lnhGFyqmpv8uXxkMGNIp 1ScQ== X-Forwarded-Encrypted: i=1; AJvYcCVXWitF/FCUuO6RNSwRk23d40/t86VfxM/bC3Sy8QjZsmwP4OEkddotZ12tQQvxaRhfZt1ifA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwYfwGVi06NKLnkOSKHqsBfjs1HssJOuGtW3GuC8XmGIE3F4JFV niVL8ID1g0Gk/aYjVud3Vy+oqGzb1Ng9ijvjMuC+fzdoe6TUDvV/ae0pXWV+bsH5DSGMuV7NX9v 4NeazMjrWRqoPqL1jEPWdTItYGzh2rK6dgepJZcre//Rf1k1605xSPKKy05pSsIIFbC41LHpGFB eAfsqMiNqpLpuPUl3PLy+tHvmcogb+sQ== X-Gm-Gg: ASbGncsukFvK6M2cC9Dfe54CABxSoomZEUwSJgrSDF5LJxv3Ykjz5V1Y06TMCGiymk+ M53TsJ4VzGsoWjQbBFPRbEA3UQdFN4X3u1O6oU9T4mvYYVIyjkSzil768YkZZD/P+R8BmRfdPVN /0C6c= X-Received: by 2002:a17:907:7f17:b0:ad8:9466:3348 with SMTP id a640c23a62f3a-ae6cf73f422mr267965966b.36.1752067072809; Wed, 09 Jul 2025 06:17:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFyykAqi7mofen9Ogz3dpkabVjCuMkW4dHqkb/O1EkLbrTknT9OENZN5kcvoiz7b3WxgdO6Amzzen1sMwza4eU= X-Received: by 2002:a17:907:7f17:b0:ad8:9466:3348 with SMTP id a640c23a62f3a-ae6cf73f422mr267961766b.36.1752067072363; Wed, 09 Jul 2025 06:17:52 -0700 (PDT) MIME-Version: 1.0 References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> In-Reply-To: <86tt3lindj.fsf@gnu.org> From: Spencer Baugh Date: Wed, 9 Jul 2025 09:17:41 -0400 X-Gm-Features: Ac12FXxp5Mt4bLCtOXLWoLJ1RbZc6cqdj31vzUZOvWTDP0QUQUTOLiHlnTP86XY Message-ID: Content-Type: multipart/alternative; boundary="00000000000078aac906397ee766" X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --00000000000078aac906397ee766 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 9, 2025, 8:01=E2=80=AFAM Eli Zaretskii wrote: > > From: Spencer Baugh > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > app-emacs-dev@janestreet.com > > Date: Tue, 08 Jul 2025 14:25:03 -0400 > > > > Eli Zaretskii writes: > > >> This is a general problem with AOT-compiling files which are > > >> subsequently installed somewhere else. It applies both for core Ema= cs > > >> files and for site-lisp. > > > > > > No, core Emacs files are okay and supported. > > > > > > It's compiling site-lisp files in this way is not supported. And you > > > still haven't answered my question: why do you need that? > > > > > > The supported way of compiling site-lisp files is after they are > > > installed in site-lisp. > > > > This makes it difficult to develop code that will be installed in > > site-lisp, because code which is not installed cannot be tested with th= e > > native-compilation that will be used when that code is actually > > installed. Since there are sometimes bugs in packages when used with > > native compilation, it would be better to be able to run the code befor= e > > it is installed with the same native-compilation artifacts that will be > > used when it is installed. > > Emacs 30 and later has the emacs-lisp-native-compile command, which > can be used to compile the file visited in the current buffer. The > companion command emacs-lisp-native-compile-and-load will also load > the resulting .eln file. I think these two commands can be used to > test the results of natively-compiling any Lisp file, anywhere. > Yes, but then those native compilation artifacts aren't the ones which will actually be used when Emacs is installed. So there is the possibility of differences between them, which can cause bugs which aren't caught by testing only the uninstalled version. > --00000000000078aac906397ee766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 9, 2025, 8:01=E2=80= =AFAM Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Spencer Baugh &= lt;sbaugh@janestreet.com>
> Cc: acorallo@gnu.org,=C2=A0 78783@debbugs.gnu.org,=C2=A0 app-emacs-dev@janestreet.com
> Date: Tue, 08 Jul 2025 14:25:03 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
> >> This is a general problem with AOT-compiling files which are<= br> > >> subsequently installed somewhere else.=C2=A0 It applies both = for core Emacs
> >> files and for site-lisp.
> >
> > No, core Emacs files are okay and supported.
> >
> > It's compiling site-lisp files in this way is not supported.= =C2=A0 And you
> > still haven't answered my question: why do you need that?
> >
> > The supported way of compiling site-lisp files is after they are<= br> > > installed in site-lisp.
>
> This makes it difficult to develop code that will be installed in
> site-lisp, because code which is not installed cannot be tested with t= he
> native-compilation that will be used when that code is actually
> installed.=C2=A0 Since there are sometimes bugs in packages when used = with
> native compilation, it would be better to be able to run the code befo= re
> it is installed with the same native-compilation artifacts that will b= e
> used when it is installed.

Emacs 30 and later has the emacs-lisp-native-compile command, which
can be used to compile the file visited in the current buffer.=C2=A0 The companion command emacs-lisp-native-compile-and-load will also load
the resulting .eln file.=C2=A0 I think these two commands can be used to test the results of natively-compiling any Lisp file, anywhere.

Yes, but the= n those native compilation artifacts aren't the ones which will actuall= y be used when Emacs is installed.=C2=A0 So there is the possibility of dif= ferences between them, which can cause bugs which aren't caught by test= ing only the uninstalled version.
--00000000000078aac906397ee766-- From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 13:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175206924719910 (code B ref 78783); Wed, 09 Jul 2025 13:55:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 13:54:07 +0000 Received: from localhost ([127.0.0.1]:49812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZVFO-0005B4-VK for submit@debbugs.gnu.org; Wed, 09 Jul 2025 09:54:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53110) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZVFK-0005A7-M7 for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 09:54:04 -0400 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 1uZVFF-00067j-2X; Wed, 09 Jul 2025 09:53:57 -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=WlPyRCX1PcOsT8Ej3Kf/KwMRYtmCQdjgWmLJ2mDQgC4=; b=ctzQ2St5Fdes e52lKkc1QcDDd4q8fG6OhZnfBcpx/HtPByqactCOmYreh7xoZmP9wtQAmw/1gT+VXi+BF0iV7UyPM 71aDOHLKwZbPoxzTlT76I6FyHezR4p0Ure3FQtqos5MGKzUwr/BmB8tlM5C5CMhf/aSRLL97OZSrP uAjRBVDLUvoZnHpbqbX7/CHaROWJv31wA3vM4ENYhxJvph2zy8aNBkvBLCcC8eLDK5kBoZY5Dp87t ASinWbhtLWvWCghG/xy/s+PFXFdgc4Dz5zY7N/z9aki8Fj/IvQ7IbjmS2CMRFzC1BDHfdl2fHP9c1 RBvrXBuhGNnX2dino+oUwA==; Date: Wed, 09 Jul 2025 16:53:48 +0300 Message-Id: <86ldoxii6r.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 9 Jul 2025 09:17:41 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Wed, 9 Jul 2025 09:17:41 -0400 > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > app-emacs-dev > > > > The supported way of compiling site-lisp files is after they are > > > installed in site-lisp. > > > > This makes it difficult to develop code that will be installed in > > site-lisp, because code which is not installed cannot be tested with the > > native-compilation that will be used when that code is actually > > installed. Since there are sometimes bugs in packages when used with > > native compilation, it would be better to be able to run the code before > > it is installed with the same native-compilation artifacts that will be > > used when it is installed. > > Emacs 30 and later has the emacs-lisp-native-compile command, which > can be used to compile the file visited in the current buffer. The > companion command emacs-lisp-native-compile-and-load will also load > the resulting .eln file. I think these two commands can be used to > test the results of natively-compiling any Lisp file, anywhere. > > Yes, but then those native compilation artifacts aren't the ones which will actually be used when Emacs is > installed. So there is the possibility of differences between them, which can cause bugs which aren't caught > by testing only the uninstalled version. Every file you install on the end-user machine is never the same as the one you tested on your development machine. And yet we don't say they cannot be tested. So I don't see the difference here, and don't understand why we are splitting hair. The problems you raise are barely tangible at best. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 14:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175207045027335 (code B ref 78783); Wed, 09 Jul 2025 14:15:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 14:14:10 +0000 Received: from localhost ([127.0.0.1]:51288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZVYn-00076k-JB for submit@debbugs.gnu.org; Wed, 09 Jul 2025 10:14:10 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:55481) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZVYj-00075e-Mt for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 10:14:07 -0400 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uZVYe-00000009OMv-1FWr for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 10:14:00 -0400 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-ae401eba66aso358227866b.3 for <78783@debbugs.gnu.org>; Wed, 09 Jul 2025 07:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752070439; x=1752675239; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7avs9B15blkYlYdksScaymwShjF8lgfSXCKEbKPRNdM=; b=zffmgE7p36Ey9oL0boZBJOuuGpZn5j/nYwxGAc5K0i83MhOw0Q9GPRMz+pPqvxYd+J 8doWUI/hLnEzQTZSYyRbl3EjERtT68aUXMbwKakLVYVxBaKqJ1ZNx/UBuq1+sFZiNmrT cpOue3wbnwkqQetBueAN1Bg4JokMFXRWscMRg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752070440; bh=7avs9B15blkYlYdksScaymwShjF8lgfSXCKEbKPRNdM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=J/Ct63KPkIXzIy8swul5YSyYy284EchwnbRVriKcbfuCcDkdhKdufDmtZ7aXTnbVZ uy560dGSPT3dHhlcPrvOfrbPLP1G1llguZ4xcWLSNF9BmItGJ0PxoWOFG7SApMJlVi oeQ/X9//4jhI5l1mHhhYZuaUaf+5u/4VcFdrBsAMgXaPD13Cu3Z6Z0Mpuubdkk3cCK 2n9nlbyhDWIo3AvgNWCJOPxfFUqsm3RPNuwOx94N4fS2j09D7WoQlE+1wRGDWDzKRs fSy4iopD9oc+yjocBcTd3z9h5CFeIqt6j1/ZMZlJrwRT4zLAR+tMlHLeLCpfbysoaU 6E/6UEf7tN3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752070439; x=1752675239; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7avs9B15blkYlYdksScaymwShjF8lgfSXCKEbKPRNdM=; b=wkJ8cPWZM9GpildzZofsyOu/wJ8ecV/lnIjTncW60QE/EHuGOvoVU8QiInJG80mrmd J/rM05ab5jVDUhlqOp5fjmfCYqeZd55frfk7zHdtJaNMXNGrf4q/iZN8POZpKLti5V8m h4ZUccbaqaFIlaRdpJF0wAqOfFEWUh/IYYeFuyOeqv0AxzL8YHUM3eFZ1JLN1v+mT+nq 6jgMu6USCScso3ee6j2n4pd9/kpdTDOuNDmLMUHx4oI5PoHUN53r2HUaZ1M7QhcD9V8Q J9n4A5VJW0R6UAwpg+ORmK0pi3rJoslDnl6+uohAQv5vPliSuqjzx7e0w+QH6g28CRKQ XycA== X-Forwarded-Encrypted: i=1; AJvYcCW1fuBzAM9urIsgKutnBKEy9kqSIRAHpla3iPQ00fSJixrgjbLZ6+NBAH/K1qtbOeANKhGfuA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyBeyju5xRHglWJDeXrk4zUQ9et1Srwj/fbb1t2uf139848ZiDe 45sthIucUF5Ka2jq5ZXp24qc7uFSpyXJyCniB6o9joGg93GlO9Ff1p93lxOe/EaN4U72CMY/1FL igLiEO5r5Ddt1AeD8Om7tgnh235bg4cPzctQgJjRI7BnwUGs85AfZhmueykXWKj51xL9e3QPmtF LYRHo1j5WZHycoPocufhoH1fXQe/v5Yg== X-Gm-Gg: ASbGnctlmqx3frSEKkBxMfboPAtXf1WEzF0FKY8XwKE/eFYp//L8WOy5dece0Cd2jMz VhO8Be6B8ZJ5uxnAsnWVR4p9YX2n5UMGpKp/IYuF/NGgkaOjDmqhSZi1YBcNrWNC5Mrt8X6brs3 sSMQdFKz2p71BJBiQuZf9F3J7BE2aeewbGRkm+ X-Received: by 2002:a17:907:7b88:b0:adb:449c:7621 with SMTP id a640c23a62f3a-ae6cf78c48dmr286536466b.29.1752070439280; Wed, 09 Jul 2025 07:13:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGVEWiWanG/FSZ+KdirJS+PtPqyONuvoagw9Ibeh4HtQLk6lixSSC8/0vbXUacUGomeBAVF3NbP13GzOmNE544= X-Received: by 2002:a17:907:7b88:b0:adb:449c:7621 with SMTP id a640c23a62f3a-ae6cf78c48dmr286532966b.29.1752070438866; Wed, 09 Jul 2025 07:13:58 -0700 (PDT) MIME-Version: 1.0 References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> In-Reply-To: <86ldoxii6r.fsf@gnu.org> From: Spencer Baugh Date: Wed, 9 Jul 2025 10:13:48 -0400 X-Gm-Features: Ac12FXxVzabIK_5VIoCE-qjcTlJ7wHbsQX4fDn1jgViz3L5fwpoOpzlxVU4do00 Message-ID: Content-Type: multipart/alternative; boundary="000000000000215ea506397fb038" X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --000000000000215ea506397fb038 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 9, 2025, 9:53=E2=80=AFAM Eli Zaretskii wrote: > > From: Spencer Baugh > > Date: Wed, 9 Jul 2025 09:17:41 -0400 > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > > app-emacs-dev > > > > > > The supported way of compiling site-lisp files is after they are > > > > installed in site-lisp. > > > > > > This makes it difficult to develop code that will be installed in > > > site-lisp, because code which is not installed cannot be tested with > the > > > native-compilation that will be used when that code is actually > > > installed. Since there are sometimes bugs in packages when used wit= h > > > native compilation, it would be better to be able to run the code > before > > > it is installed with the same native-compilation artifacts that will > be > > > used when it is installed. > > > > Emacs 30 and later has the emacs-lisp-native-compile command, which > > can be used to compile the file visited in the current buffer. The > > companion command emacs-lisp-native-compile-and-load will also load > > the resulting .eln file. I think these two commands can be used to > > test the results of natively-compiling any Lisp file, anywhere. > > > > Yes, but then those native compilation artifacts aren't the ones which > will actually be used when Emacs is > > installed. So there is the possibility of differences between them, > which can cause bugs which aren't caught > > by testing only the uninstalled version. > > Every file you install on the end-user machine is never the same as > the one you tested on your development machine. And yet we don't say > they cannot be tested. > When I compile a .o on my machine and then copy it to a user machine and run it there, it is the same file, because it has the same contents and the same name. So I don't see the difference here, and don't understand why we are > splitting hair. The problems you raise are barely tangible at best. > The other issue is that in my build system, when automated tests are run they are run in a temporary directory with a randomized name. This means that the native compilation has to happen separately in every test. This is much too slow; it would be better to be able to native compile once and share that native compilation between all tests, like can be done with byte compilation. > --000000000000215ea506397fb038 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 9, 2025, 9:53=E2=80= =AFAM Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Spencer Baugh &= lt;sbaugh@janestreet.com>
> Date: Wed, 9 Jul 2025 09:17:41 -0400
> Cc: acorallo@gnu.org, 78783@debbugs.gnu.org,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0app-emacs-dev <app-emacs-dev@ja= nestreet.com>
>
>=C2=A0 > > The supported way of compiling site-lisp files is afte= r they are
>=C2=A0 > > installed in site-lisp.
>=C2=A0 >
>=C2=A0 > This makes it difficult to develop code that will be instal= led in
>=C2=A0 > site-lisp, because code which is not installed cannot be te= sted with the
>=C2=A0 > native-compilation that will be used when that code is actu= ally
>=C2=A0 > installed.=C2=A0 Since there are sometimes bugs in packages= when used with
>=C2=A0 > native compilation, it would be better to be able to run th= e code before
>=C2=A0 > it is installed with the same native-compilation artifacts = that will be
>=C2=A0 > used when it is installed.
>
>=C2=A0 Emacs 30 and later has the emacs-lisp-native-compile command, wh= ich
>=C2=A0 can be used to compile the file visited in the current buffer.= =C2=A0 The
>=C2=A0 companion command emacs-lisp-native-compile-and-load will also l= oad
>=C2=A0 the resulting .eln file.=C2=A0 I think these two commands can be= used to
>=C2=A0 test the results of natively-compiling any Lisp file, anywhere.<= br> >
> Yes, but then those native compilation artifacts aren't the ones w= hich will actually be used when Emacs is
> installed.=C2=A0 So there is the possibility of differences between th= em, which can cause bugs which aren't caught
> by testing only the uninstalled version.

Every file you install on the end-user machine is never the same as
the one you tested on your development machine.=C2=A0 And yet we don't = say
they cannot be tested.

When I compile a .o on my machine and then copy it to= a user machine and run it there, it is the same file, because it has the s= ame contents and the same name.

So I don't see the difference here, and don't understand why we are=
splitting hair.=C2=A0 The problems you raise are barely tangible at best.

Th= e other issue is that in my build system, when automated tests are run they= are run in a temporary directory with a randomized name.=C2=A0 This means = that the native compilation has to happen separately in every test.=C2=A0 T= his is much too slow; it would be better to be able to native compile once = and share that native compilation between all tests, like can be done with = byte compilation.
--000000000000215ea506397fb038-- From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 15:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175207638722291 (code B ref 78783); Wed, 09 Jul 2025 15:54:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 15:53:07 +0000 Received: from localhost ([127.0.0.1]:51684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZX6Z-0005nP-21 for submit@debbugs.gnu.org; Wed, 09 Jul 2025 11:53:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38470) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZX6V-0005m1-4l for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 11:53:05 -0400 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 1uZX6P-0004kJ-2Y; Wed, 09 Jul 2025 11:52:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=FL+voVE8ILM+h4qASM8Wd402bXhDXwWkua/rQrJ18zo=; b=Xq8nh9Zo/jByGvyegSeh RQy6tiRp5BoFcn29rjHqlorY0uFV7wycWWCrRQz86TUrXXiFyYy3eD17/V5G9pyl/hJUGUE7dzS6I xXXiI7UOr0+Jn8hcWhnbAj6wf6nIJ9TsHev8q/t7LZhEeRYq/mYzY65N3ihu96RIXGLaibQCUuP+B iB5+7RejP7TvJ8EnSUZ2m6tkyIrnUFZgOMeU3pwVPScfWIPZRyT3auot4N987V019lXHHZcnkv+qJ VcV9R+ttxd5HYsSRZhZNSTccv4vopqUGrNjeF6ddLA/oOy3os9KuoqKrNu3iDQ93Um+vm/ftCAA3r gR8MIDki6uxiDA==; Date: Wed, 09 Jul 2025 18:52:53 +0300 Message-Id: <86jz4hicoa.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 9 Jul 2025 10:13:48 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Wed, 9 Jul 2025 10:13:48 -0400 > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > app-emacs-dev > > On Wed, Jul 9, 2025, 9:53 AM Eli Zaretskii wrote: > > > Emacs 30 and later has the emacs-lisp-native-compile command, which > > can be used to compile the file visited in the current buffer. The > > companion command emacs-lisp-native-compile-and-load will also load > > the resulting .eln file. I think these two commands can be used to > > test the results of natively-compiling any Lisp file, anywhere. > > > > Yes, but then those native compilation artifacts aren't the ones which will actually be used when > Emacs is > > installed. So there is the possibility of differences between them, which can cause bugs which aren't > caught > > by testing only the uninstalled version. > > Every file you install on the end-user machine is never the same as > the one you tested on your development machine. And yet we don't say > they cannot be tested. > > When I compile a .o on my machine and then copy it to a user machine and run it there, it is the same file, > because it has the same contents and the same name. You can only do that if the other machine has exactly the same architecture and the same versions of system libraries. See bug#78907 for what happens otherwise. > So I don't see the difference here, and don't understand why we are > splitting hair. The problems you raise are barely tangible at best. > > The other issue is that in my build system, when automated tests are run they are run in a temporary > directory with a randomized name. This means that the native compilation has to happen separately in > every test. This is much too slow; it would be better to be able to native compile once and share that native > compilation between all tests, like can be done with byte compilation. If you are trying to argue that we should give up the strict testing which is precondition for loading a .eln file, then it's not going to happen, sorry. Crashing an Emacs session due to some incompatibilities we avoid this way is a much higher price to pay than what you describe, even if there's no better solutions within the current restrictions. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 16:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.17520778734422 (code B ref 78783); Wed, 09 Jul 2025 16:18:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 16:17:53 +0000 Received: from localhost ([127.0.0.1]:51778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZXUT-00018u-LV for submit@debbugs.gnu.org; Wed, 09 Jul 2025 12:17:52 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:44639) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZXUO-00017H-35 for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 12:17:47 -0400 Received: from mail-ej1-f70.google.com ([209.85.218.70]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uZXUI-00000009gxA-2GVF for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 12:17:38 -0400 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-ad56a52edc5so1131866b.0 for <78783@debbugs.gnu.org>; Wed, 09 Jul 2025 09:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752077857; x=1752682657; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9i0FNcgRlSu+zbtD/hrfT1c8nqnw96MIoOttjYSAfKc=; b=q2yQY5CoFiUDE++YZZrqD7gELg2LHMiVkSs8R/t24kfj7NDDMa4155Z+aebds5G9G6 RdhBuiKADBxWCHRPmYDMhAL8m482ntylhJsSgaR7Dop4scGQ4j4xnfTT6DQrvj+WobsZ 6+6s5szMSYT7g+P3vM1RN0gUmD09AIEoudqQI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752077858; bh=9i0FNcgRlSu+zbtD/hrfT1c8nqnw96MIoOttjYSAfKc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=s8kf3vclBoKKcHDKHG+uwcgSP4zCoPONcv1F7Qkpz/XPxtTtv2NoNlOIbZdlhwa1p caIMZdHSRXOtglntj9WQndlJ+rWb0LNhJJYJLbCThkr4IqsHlSMQcYT6vQvLZEzEzJ gle0tRFByYEoF5B1IGCtzWjiDAkNW7pY/9lefy98p4hPh6UjkWF4r4H0BFpViloimI jItu49UT9gH+RBqSjWTd2uidZcVcdDcVs8FnVVxmjwFUCH2MFpqmZEDq1Or02NGjOU 0+lATfoRU9cYerp/8NUyFMeYquyW/qfwf3lZ0kIhTmG0m2XSzsZaDx7xl50dWdx8BM HjSBpNGPWaS9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752077857; x=1752682657; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9i0FNcgRlSu+zbtD/hrfT1c8nqnw96MIoOttjYSAfKc=; b=ssaATGXCJ/UY0WM4hCEPZhpa5R1bhBUCxuGKPdS+VclI4d/LwQsSzhpJbmxSQJCrAg /azU70tcFs6z5q+zh/QnWlW5AJRbRjdJk7/lCaZVKrDae3ldBr4rWK04kDJBDwyUEI+t 9G0DK+XvkpUmHRaORM1QEovIaNfRnQ7X1biUIgqmcjsN6XotgEvsqYh2cwfUG7VbZayu wwpP9bRUg1Qjbg7mzk1b02Wo31i+OQGHh+I7G1LDtcMxq10Xgnc/EkeFVOHCkt0jDpOC cnNq/dcTXP+k9iq8xPNca08UUy1zWXXvX3FVFzj5Wc5W+dPGFxEB5QHtHkDncz/5qUT6 tgUw== X-Forwarded-Encrypted: i=1; AJvYcCWKYWoxH4ddFcN+9kYy5J1tfyqVeWew/msVZrUNMyGCEwSVREiprL9fKD8J1eC6oMGs6zAS1A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxiW6tFRnk6uWGpdoynvBk+fdXxddF8L2oIG1mtffGjFILsns4z 4c4jjOstkzI7Ddv9Qdjqc1niE1B/hHCwmzF1ZVJmVOjHNJxQHsfHR8Ck2xdl/MCju1ZKW0Qe57i siFf5qXDc8BkNAthwbF2tH9EMk9QVYxnxmMT3ZgOdzlqYIWjYqoWm2rI+tV1iNscudtNfnyxoJR WcZ29F4K5poDEbaInqKbAGRF8s9K1BYg== X-Gm-Gg: ASbGncsvZq6osiCM68Df4pAD4CwG7guck/TH0B4EWZcLH7u9ua8EdqB1+00k/mF3qYb 0aqZzlAd1SSfkc6VS741FWOGHCz9WtG8DL8uKMc/UBYGuM1b8Ts7Pm1Iubo6wa0Y3f3NL6k7qfc lz9Rs= X-Received: by 2002:a17:907:7b8e:b0:ade:4121:8d52 with SMTP id a640c23a62f3a-ae6cf5a2fdamr375551866b.16.1752077857587; Wed, 09 Jul 2025 09:17:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGojk3PIzkxJVcTzamxa7dJjzGjEE3ErHgrF2BLhhO7/9UpbZjZsL3ci+fvPhF5rmtUpk419s8YuGIPWXyeNjE= X-Received: by 2002:a17:907:7b8e:b0:ade:4121:8d52 with SMTP id a640c23a62f3a-ae6cf5a2fdamr375548366b.16.1752077857086; Wed, 09 Jul 2025 09:17:37 -0700 (PDT) MIME-Version: 1.0 References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> In-Reply-To: <86jz4hicoa.fsf@gnu.org> From: Spencer Baugh Date: Wed, 9 Jul 2025 12:17:26 -0400 X-Gm-Features: Ac12FXwnBLbv0KYdSxMOCiEa4LpiQ6Oz-q4q9hUc4eIpWQgVFEFgG7tOJAdt_VA Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Wed, Jul 9, 2025 at 11:52=E2=80=AFAM Eli Zaretskii wrote: > > > From: Spencer Baugh > > Date: Wed, 9 Jul 2025 10:13:48 -0400 > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > > app-emacs-dev > > > > On Wed, Jul 9, 2025, 9:53=E2=80=AFAM Eli Zaretskii wrote= : > > > > > Emacs 30 and later has the emacs-lisp-native-compile command, which > > > can be used to compile the file visited in the current buffer. The > > > companion command emacs-lisp-native-compile-and-load will also load > > > the resulting .eln file. I think these two commands can be used to > > > test the results of natively-compiling any Lisp file, anywhere. > > > > > > Yes, but then those native compilation artifacts aren't the ones whi= ch will actually be used when > > Emacs is > > > installed. So there is the possibility of differences between them,= which can cause bugs which aren't > > caught > > > by testing only the uninstalled version. > > > > Every file you install on the end-user machine is never the same as > > the one you tested on your development machine. And yet we don't say > > they cannot be tested. > > > > When I compile a .o on my machine and then copy it to a user machine an= d run it there, it is the same file, > > because it has the same contents and the same name. > > You can only do that if the other machine has exactly the same > architecture and the same versions of system libraries. See bug#78907 > for what happens otherwise. Yes, of course. But this is how package managers work: they provide binaries that are compiled on one machine and then installed on many user machines, and this works because they are careful to use binaries on the same architecture and with the same system libraries. > > So I don't see the difference here, and don't understand why we are > > splitting hair. The problems you raise are barely tangible at best. > > > > The other issue is that in my build system, when automated tests are ru= n they are run in a temporary > > directory with a randomized name. This means that the native compilati= on has to happen separately in > > every test. This is much too slow; it would be better to be able to na= tive compile once and share that native > > compilation between all tests, like can be done with byte compilation. > > If you are trying to argue that we should give up the strict testing > which is precondition for loading a .eln file, then it's not going to > happen, sorry. Crashing an Emacs session due to some > incompatibilities we avoid this way is a much higher price to pay than > what you describe, even if there's no better solutions within the > current restrictions. The strict testing done by comp-el-to-eln-rel-filename is deliberately weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH: part of the filename is ignored and not checked. I am simply suggesting that we should do the same exact thing for files under PATH_SITELOADSEARCH. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 17:37:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175208260017915 (code B ref 78783); Wed, 09 Jul 2025 17:37:03 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 17:36:40 +0000 Received: from localhost ([127.0.0.1]:52222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZYil-0004er-LG for submit@debbugs.gnu.org; Wed, 09 Jul 2025 13:36:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41322) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZYii-0004dD-W8 for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 13:36:37 -0400 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 1uZYic-0000Pu-Ms; Wed, 09 Jul 2025 13:36:30 -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=zyVzpoXBAR5R2l/HftK+uywcmsn8no4KJwx0CuqQBDk=; b=pkHGXy69xOt4 QEpYBJv993hOyx1pvMP5Ycq34pC3A8LHKkjfrWWr9xavGuuZPqMP8+Vd35gCqaVfFy2654kRGQbuz T3Hs4KEdTo9XiSgp001JAY1EdCdrLS9C6SPwmjBkp7Ei36mYwrDZzRhEdpRPVBcxN3kvvJg3JxJNw PkGI56I/bjmxP6eeL4YNVdB1ffEmoAEBoF4z94TMQwUcov7P2le3mp5AyoRL9HCSytRkOTXM6laCZ lOm0GFU9m5pS/fkl+3yxTVxqiCcIJ8CGKTjHO8mIC5Ik1DKwtwZj3/YzEuox33V3pUAWzzctHclbj yqWqcpheyeBu0TNOpNS6qg==; Date: Wed, 09 Jul 2025 20:36:27 +0300 Message-Id: <86cya9i7vo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 9 Jul 2025 12:17:26 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Wed, 9 Jul 2025 12:17:26 -0400 > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com > > > > When I compile a .o on my machine and then copy it to a user machine and run it there, it is the same file, > > > because it has the same contents and the same name. > > > > You can only do that if the other machine has exactly the same > > architecture and the same versions of system libraries. See bug#78907 > > for what happens otherwise. > > Yes, of course. But this is how package managers work: they provide > binaries that are compiled on one machine and then installed on many > user machines, and this works because they are careful to use binaries > on the same architecture and with the same system libraries. If the architecture is the same, you can take the *.eln files you compiled on your system and install them on the end-user's one. So I don't see a problem to begin with -- you should be able to solve your problem with a local solution. > > If you are trying to argue that we should give up the strict testing > > which is precondition for loading a .eln file, then it's not going to > > happen, sorry. Crashing an Emacs session due to some > > incompatibilities we avoid this way is a much higher price to pay than > > what you describe, even if there's no better solutions within the > > current restrictions. > > The strict testing done by comp-el-to-eln-rel-filename is deliberately > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH: > part of the filename is ignored and not checked. I am simply > suggesting that we should do the same exact thing for files under > PATH_SITELOADSEARCH. I don't see the need. The Emacs build doesn't compile any files inside directories on that path, so there's no reason for the upstream project to complicate the code on behalf of situations that don't happen when Emacs is built. There should be no problem for you to do it with your local arrangements. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jul 2025 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175208301322536 (code B ref 78783); Wed, 09 Jul 2025 17:44:02 +0000 Received: (at 78783) by debbugs.gnu.org; 9 Jul 2025 17:43:33 +0000 Received: from localhost ([127.0.0.1]:52250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZYpQ-0005rQ-KW for submit@debbugs.gnu.org; Wed, 09 Jul 2025 13:43:33 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:51177) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZYpN-0005q8-ER for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 13:43:30 -0400 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uZYpH-00000009qK2-3Th9 for 78783@debbugs.gnu.org; Wed, 09 Jul 2025 13:43:23 -0400 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-ad56a52edc5so8785666b.0 for <78783@debbugs.gnu.org>; Wed, 09 Jul 2025 10:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752083003; x=1752687803; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eifROpnz1z4twYSbU77BBJJkg4XPbhGrF20AZGNdlRs=; b=wzvhC7tM3AOSFoeTFAT73I/ifN+ATn9rD9bOD1sHOWNtHaSnOr2FtP79hMMfD+1xvM lNS094TlMIGobKEN9VGn5ej0HuwPedMplniHsF0clFu6TJVm0FfXWngSClI07zSjHLzW Uec/jMJFk/6l/ifH2cs2/o+27c26LdMOqQlyo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752083003; bh=eifROpnz1z4twYSbU77BBJJkg4XPbhGrF20AZGNdlRs=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=LiikpVxsZDJ4F5h18GIwL11WxrqFaTCvthCzLdsXiogPjCkcw9J6HOew0wKam+orn +GbFJkFZAJGFuQQHvPRzHJPXLG9HvOdFweYK+A5BYjNAFZ8GTVMO5sPqpDOCmyr2Hk 8QD4MQvC27bdb+AhnhGx20EIqK4WHQygSIIn58d6sZnqQ3Nvkp4stFanzGO73VrkRg tNHdoZ0FxVuihOn3jMD9LDkNExnyLFbZZyO7QXuUt5z7XGsJ0rin4BDABBJkcRNxa8 aSC1FwHGlcS490P2+2GGbPj9FGl8bN9RD2wsJSFUFOb90Q5M9Kd8a8UICaqlXqKMd0 /muViU8AFhTBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752083003; x=1752687803; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eifROpnz1z4twYSbU77BBJJkg4XPbhGrF20AZGNdlRs=; b=Z2W0RHppkiD3em9/x1jNYcziDvVC0tZa2PB2VqWTy+OA+ypoGb12PQfvkLj4fliazn jGk8reLrdhCSbsCLxI73NQVgA8DTEd/ILgzAod0zU+UqKsjk4eqSFt6t6C2Tm7yCx1q1 /vng51DzaB84PUIrK3TjP9HUrO06GsJvHp5GVDGObWne+vVWWkDlY0pvQSfy7lGK7yJM 7HywjlVJ6OmaotPvyMtLsfT7g0hTA2TPBiDtf9yv+u4MvSuLbztFHmnDa90Ukjw4HFF9 jcYoMmzISTe6FIfk4zr+IZOVJH7q0MVKMG9GwB2tiQ6GcLcS7o2lyFv6INhaMBeI722e Tu3w== X-Forwarded-Encrypted: i=1; AJvYcCUomghZi//V461t1jC1AhSNb29dp1u5hOegUZJi/6iKzPA6+js4O37zyXJP1wfS0QFZ0wJQCg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YytN+jonu7Zn6SvouhpRJp+l/H4EkxP9ibuW8hfLBlo2u172kSu vKr6Yv/s3EwzB93svE1Kn3lS4B+SR9YUVhPk/Cwjcs2OZJdamqubPRrTvusHR7LEz5KvoF/gwJR Uy366osHBQ1ByZfVNIyxuRHquTQBj6KRSeFAwtOYWiBqr+N3oqTEq9FEORUVudZslH0Lpqymyqs NkwzXUmZJHEUj0ODYfNBtBUrCHbUiDqA== X-Gm-Gg: ASbGnct0Uy+6Fm1y9RTyUlE4jmuMPnMzrRZUxg1HBPR0U948DkyNbiYGhcewwgFg+Dz BRAgc7KPmxAhyxpyHm5Po9MlxLaNPZcWTuQtSFcHAeq5bHE4YOVTSyW6/Ov3ZyFiGRv+l5jGeAP YrNfg= X-Received: by 2002:a17:907:1c10:b0:ae0:de4a:3153 with SMTP id a640c23a62f3a-ae6cf70d8cdmr386782766b.38.1752083002848; Wed, 09 Jul 2025 10:43:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF4B3lSbMl4McwQfWveqruW8FzNSmG6iXiKyUII5yAwJETVEuWQJvr4wwS1QZComneRWhe+0BpCVr5/KGU8G4Y= X-Received: by 2002:a17:907:1c10:b0:ae0:de4a:3153 with SMTP id a640c23a62f3a-ae6cf70d8cdmr386780866b.38.1752083002460; Wed, 09 Jul 2025 10:43:22 -0700 (PDT) MIME-Version: 1.0 References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> <86cya9i7vo.fsf@gnu.org> In-Reply-To: <86cya9i7vo.fsf@gnu.org> From: Spencer Baugh Date: Wed, 9 Jul 2025 13:43:11 -0400 X-Gm-Features: Ac12FXxKn8LB6_Ef4LMiN8lI541NBrxiduVDrRGAPwAHMh-vXDHuETCeg08FXKY Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Wed, Jul 9, 2025 at 1:36=E2=80=AFPM Eli Zaretskii wrote: > > > From: Spencer Baugh > > Date: Wed, 9 Jul 2025 12:17:26 -0400 > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.c= om > > > > > > When I compile a .o on my machine and then copy it to a user machin= e and run it there, it is the same file, > > > > because it has the same contents and the same name. > > > > > > You can only do that if the other machine has exactly the same > > > architecture and the same versions of system libraries. See bug#7890= 7 > > > for what happens otherwise. > > > > Yes, of course. But this is how package managers work: they provide > > binaries that are compiled on one machine and then installed on many > > user machines, and this works because they are careful to use binaries > > on the same architecture and with the same system libraries. > > If the architecture is the same, you can take the *.eln files you > compiled on your system and install them on the end-user's one. So I > don't see a problem to begin with -- you should be able to solve your > problem with a local solution. Not if those *.eln files were compiled before installing Emacs, e.g. with emacs-lisp-native-compile as you suggested. > > > If you are trying to argue that we should give up the strict testing > > > which is precondition for loading a .eln file, then it's not going to > > > happen, sorry. Crashing an Emacs session due to some > > > incompatibilities we avoid this way is a much higher price to pay tha= n > > > what you describe, even if there's no better solutions within the > > > current restrictions. > > > > The strict testing done by comp-el-to-eln-rel-filename is deliberately > > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH: > > part of the filename is ignored and not checked. I am simply > > suggesting that we should do the same exact thing for files under > > PATH_SITELOADSEARCH. > > I don't see the need. The Emacs build doesn't compile any files > inside directories on that path, so there's no reason for the upstream > project to complicate the code on behalf of situations that don't > happen when Emacs is built. There should be no problem for you to do > it with your local arrangements. What local arrangement are you suggesting? I can indeed locally patch comp-el-to-eln-rel-filename to ignore part of the filename for files under PATH_SITELOADSEARCH, and that's my current plan, if you think this is reasonable. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2025 04:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175212303518201 (code B ref 78783); Thu, 10 Jul 2025 04:51:02 +0000 Received: (at 78783) by debbugs.gnu.org; 10 Jul 2025 04:50:35 +0000 Received: from localhost ([127.0.0.1]:54270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZjEw-0004jL-3j for submit@debbugs.gnu.org; Thu, 10 Jul 2025 00:50:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43504) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZjEt-0004iK-8j for 78783@debbugs.gnu.org; Thu, 10 Jul 2025 00:50:31 -0400 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 1uZjEk-0001ha-KQ; Thu, 10 Jul 2025 00:50:23 -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=4FjoBhChy2O2eNHB44IN8eZ0iQnsJEaxtG9wcjNgQN8=; b=F0vwlQ7s6gA4 kVd5/T2SYyAIABKUIo4fJlFZnc5U8ixywiaChlyj2zrcr1Swx00X89e4pq/38iB/QIjhsnX9KRXT4 MdZLl4i/sEFNcC9MDhm0PTALAnbGajua+jA+lb61j7ldLjVZybe/k4yp4tVtW5xW2nKtPiJisVwS5 cgZhADj8ZIUyiEQ5d3w0of4tcB8DPEtgfa/RZj7Qs1ZmM5q8btXQskrxdWX1lGgYzfiZLy/G+yD4h sNnFmuSUelW+8tCkQ4AzaI1HWmEhF/sEfMpGGhz7YTlKXFdM8TM2wNMu6N0NtJ6dszRBu9hH2O6l4 Rmjt56V6jmzlM6COpd4F/Q==; Date: Thu, 10 Jul 2025 07:50:17 +0300 Message-Id: <867c0gir92.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 9 Jul 2025 13:43:11 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> <86cya9i7vo.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Wed, 9 Jul 2025 13:43:11 -0400 > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com > > > If the architecture is the same, you can take the *.eln files you > > compiled on your system and install them on the end-user's one. So I > > don't see a problem to begin with -- you should be able to solve your > > problem with a local solution. > > Not if those *.eln files were compiled before installing Emacs, e.g. > with emacs-lisp-native-compile as you suggested. Then do it after installing Emacs on the machine which produces the packages, and then add the resulting *.eln files to the package. Or do something else; the tools are all there at your disposal. > > > The strict testing done by comp-el-to-eln-rel-filename is deliberately > > > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH: > > > part of the filename is ignored and not checked. I am simply > > > suggesting that we should do the same exact thing for files under > > > PATH_SITELOADSEARCH. > > > > I don't see the need. The Emacs build doesn't compile any files > > inside directories on that path, so there's no reason for the upstream > > project to complicate the code on behalf of situations that don't > > happen when Emacs is built. There should be no problem for you to do > > it with your local arrangements. > > What local arrangement are you suggesting? I don't know! You haven't explained the rationale for the urge to AOT-compile the files in site-lisp, nor even why they need to be in site-lisp (and not in your Emacs tree, where you build) in the first place. You haven't explained why you cannot natively-compile the files after the build is complete, directing the *.eln files to some shared directory, and package those *.eln files together with the rest of the built Emacs. And you haven't explained many other aspects. Which you don't need to do if you implement your own local solution for your local problem, but without which you cannot expect us to suggest the solution of the problem for you. My point is that I don't see a need for the Emacs upstream project to support AOT native compilation of site-lisp files, because files in site-lisp are by definition the responsibility of a site. The Emacs project is not obliged to accommodate every single quirk of every downstream distribution. We provide the tools and the source code for you to use and change as you see fit, and I see several possible avenues of approach for this issue that you could have taken for solving your problem locally. But for some reason, you reject all the proposals, and insist on having something in upstream Emacs. > I can indeed locally patch comp-el-to-eln-rel-filename to ignore > part of the filename for files under PATH_SITELOADSEARCH, and that's > my current plan, if you think this is reasonable. I don't think it's reasonable, but it's your distribution and your users you are putting at risk. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2025 10:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175214218115954 (code B ref 78783); Thu, 10 Jul 2025 10:10:03 +0000 Received: (at 78783) by debbugs.gnu.org; 10 Jul 2025 10:09:41 +0000 Received: from localhost ([127.0.0.1]:55918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZoDk-000493-7U for submit@debbugs.gnu.org; Thu, 10 Jul 2025 06:09:41 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:50449) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZoDg-00047f-UP for 78783@debbugs.gnu.org; Thu, 10 Jul 2025 06:09:38 -0400 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uZoDb-0000000B2IQ-2C8r for 78783@debbugs.gnu.org; Thu, 10 Jul 2025 06:09:31 -0400 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-ae371f9e3f5so179697466b.1 for <78783@debbugs.gnu.org>; Thu, 10 Jul 2025 03:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752142170; x=1752746970; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VB0fN1bcS4zLio0eyfgDokz4n3elxbGp3V7blqL7ELU=; b=XcoWc9Tnt6akc/QtV9v/j2ToUEuLvAfQdvSf/qKKAkD8XYV7HeyBaAWiBMM5GlKof/ TUuHQ7a/1sn/zbA2VkUmdg2nPcLdR7Y68umZdaHfLNP1K4+sarigp1+u0CSMPEifljsU fXM6kJVVvRIJWgwVk7+X2kc0+alKzGUouxYFw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752142171; bh=VB0fN1bcS4zLio0eyfgDokz4n3elxbGp3V7blqL7ELU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=cTVp3YECtu8ncQ/PpKq0Gn3TzhtP8p+KJ8ohGbW0E3y4uqdtPURj/yL90h3sjYUWC ZY9b6C0uZklV/AxQRoIKlHmNOH4nKCZ4B16xgtN/VmddxCKd064993nCrrDr/OWzwT xPEUJ4Xt/Sw4Vk6InP9+MNU4xzI6KLk13TQ+h7GbgQ0yNq7prSGmUSg7szEc8++7Rz a6aKdvREOYFLilsEkYK35+l/NTk1/sJOkpDBXwb0U5m6U310VCww9CmzECKTzzcB8I 29myjjDAuwkpnW9tTBfwDx5ruXKf5pjvIUlbxkK0XJhuHmI/zuVDaWOl+dHX4KlQCR W8F3LM2wRUttw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752142170; x=1752746970; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VB0fN1bcS4zLio0eyfgDokz4n3elxbGp3V7blqL7ELU=; b=Yzt+in2xls1hx971Bx4kKyjFzD+rpjxKrqtjANLX9AMKE0aT2IflhE3+K4zk0KitbN lroQ/qiZeo39Ceiq7wLi52Prxnvgu1vBcFRWezgbIzu2yvitZHG3DGwYUdqFOTqLPvw7 cDAKicR/16J6QmQOoylzA4ilh9sYDIdeyiVPl3f9so8y8LBinoYmrOh3fYn2Q0H/yQTq 6YHdM5QRRbeKcccEYCT7Ei+fIYFN9jFydlAjYYM4WT+IGNzGX/oSkKIT+ZJTM8y4VRR+ EJGblt9WlJJx4MjJReut6qE1KhmsN6hi2vVUcnQeIF8w0h6d96PSg5WvWm7kaVhkETa+ 6nng== X-Forwarded-Encrypted: i=1; AJvYcCXlxELQfrx8jonT2hPdEOKO3WaTwqMR92L6I1EgUaJuHnZprDGttV4sjc2ftySRN/Tsd7dfCg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy5FX5AlxNksPfFZe5NA8qKZ4yKOXkyh7/ObdlSvqPrQ1DbrQZ1 L33kj9qBCkzisqZFVmC4i7r60PWz8LuRFLiXCOjp4vAwhvWtLNmCm7P5Krs2VGtEi77rCISXt7U IRlLGZ/hJo4hsP3n3H6HjRCiIrX3Il206hcTXGubTpu2+/YfvK5vmt7ZGKivrSh8+PcfuSD/wL6 WPpl/PIe4oGALimLMyYN0SetudJSUXGQ== X-Gm-Gg: ASbGncvbspg8aLZH6bROfic4re2UfAv/zXLU+bK1VDD7hacSU7V3LJXfc0pRRWP/o76 bQgdHyGtCh3bUsQ8RLzS8U2o339ots3FUA0pIE1Tiz/QlfYa43vadaZHeznBXKvMHr0y5FR1xl5 WZcgM= X-Received: by 2002:a17:906:9f91:b0:ae0:7e95:fb with SMTP id a640c23a62f3a-ae6e227c889mr284125666b.5.1752142170386; Thu, 10 Jul 2025 03:09:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF73th5AoQBjX6lckZ+A8RVViH5uV1lf+aL8O3lRMYezYwwE1VKcn5I38ZwD7VehklmwqpWLVae9HS/NMDTryo= X-Received: by 2002:a17:906:9f91:b0:ae0:7e95:fb with SMTP id a640c23a62f3a-ae6e227c889mr284122866b.5.1752142169983; Thu, 10 Jul 2025 03:09:29 -0700 (PDT) MIME-Version: 1.0 References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> <86cya9i7vo.fsf@gnu.org> <867c0gir92.fsf@gnu.org> In-Reply-To: <867c0gir92.fsf@gnu.org> From: Spencer Baugh Date: Thu, 10 Jul 2025 06:09:20 -0400 X-Gm-Features: Ac12FXxQq2lupDpzudZVQkqG-a-5GWmcryx4cLRwAElY7VtiLcoePsq3LCDbVr4 Message-ID: Content-Type: multipart/alternative; boundary="000000000000a362260639906335" X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --000000000000a362260639906335 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 10, 2025, 12:50=E2=80=AFAM Eli Zaretskii wrote: > > From: Spencer Baugh > > Date: Wed, 9 Jul 2025 13:43:11 -0400 > > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.c= o > m > > > The strict testing done by comp-el-to-eln-rel-filename is deliberatel= y > > > > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH= : > > > > part of the filename is ignored and not checked. I am simply > > > > suggesting that we should do the same exact thing for files under > > > > PATH_SITELOADSEARCH. > > > > > > I don't see the need. The Emacs build doesn't compile any files > > > inside directories on that path, so there's no reason for the upstrea= m > > > project to complicate the code on behalf of situations that don't > > > happen when Emacs is built. There should be no problem for you to do > > > it with your local arrangements. > > > > What local arrangement are you suggesting? > > I don't know! You haven't explained the rationale for the urge to > AOT-compile the files in site-lisp, To save compute and storage space on the user's machines by avoiding them needing to native compile thousands of files every time the Emacs binary changes. nor even why they need to be in > site-lisp (and not in your Emacs tree, where you build) in the first > place. No reason. They can move to the Emacs tree instead of site-lisp if that's the correct place to put hundreds of ELPA packages that are bundled with Emacs at my site. I'll do that if that's what you suggest. You haven't explained why you cannot natively-compile the > files after the build is complete, directing the *.eln files to some > shared directory, and package those *.eln files together with the rest > of the built Emacs. Because the native compilation doesn't just need to happen after the build is complete, but also after Emacs is installed, because comp-el-to-eln-rel-filename refuses to use native compilation artifacts that were produced before Emacs was installed, because of its strict filename checking. Except that it has a special exception for .el files shipped with Emacs, which could be extended to site-lisp. And you haven't explained many other aspects. > Which you don't need to do if you implement your own local solution > for your local problem, but without which you cannot expect us to > suggest the solution of the problem for you. > > My point is that I don't see a need for the Emacs upstream project to > support AOT native compilation of site-lisp files, because files in > site-lisp are by definition the responsibility of a site. The Emacs > project is not obliged to accommodate every single quirk of every > downstream distribution. We provide the tools and the source code for > you to use and change as you see fit, and I see several possible > avenues of approach for this issue that you could have taken for > solving your problem locally. But for some reason, you reject all the > proposals, and insist on having something in upstream Emacs. > > > I can indeed locally patch comp-el-to-eln-rel-filename to ignore > > part of the filename for files under PATH_SITELOADSEARCH, and that's > > my current plan, if you think this is reasonable. > > I don't think it's reasonable, but it's your distribution and your > users you are putting at risk. > Why isn't it reasonable? Andrea has previously commented in other bugs that the file name check is not very important in the first place; it's not about correctness, it's just a convenience for avoiding conflicts during parallel compilation. Honestly the file name check could probably be removed entirely, as it has already been weakened in other bugs. > --000000000000a362260639906335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 10, 2025, 12:50=E2= =80=AFAM Eli Zaretskii <eliz@gnu.org= > wrote:
> From: Spencer Baug= h <sbaugh@janestreet.com>
> Date: Wed, 9 Jul 2025 13:43:11 -0400
> Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-em= acs-dev@janestreet.com
> > > The strict testing done by comp-el-to-eln-rel-filename is de= liberately
> > > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOA= DSEARCH:
> > > part of the filename is ignored and not checked.=C2=A0 I am = simply
> > > suggesting that we should do the same exact thing for files = under
> > > PATH_SITELOADSEARCH.
> >
> > I don't see the need.=C2=A0 The Emacs build doesn't compi= le any files
> > inside directories on that path, so there's no reason for the= upstream
> > project to complicate the code on behalf of situations that don&#= 39;t
> > happen when Emacs is built.=C2=A0 There should be no problem for = you to do
> > it with your local arrangements.
>
> What local arrangement are you suggesting?

I don't know!=C2=A0 You haven't explained the rationale for the urg= e to
AOT-compile the files in site-lisp,
To save compute and storage space on the user's machines by avoiding= them needing to native compile thousands of files every time the Emacs bin= ary changes.

nor = even why they need to be in
site-lisp (and not in your Emacs tree, where you build) in the first
place.

No reason.=C2=A0 They can move to the Emacs tree instead of site-lisp if = that's the correct place to put hundreds of ELPA packages that are bund= led with Emacs at my site.=C2=A0 I'll do that if that's what you su= ggest.

=C2=A0 You h= aven't explained why you cannot natively-compile the
files after the build is complete, directing the *.eln files to some
shared directory, and package those *.eln files together with the rest
of the built Emacs.

Because the native compilation doesn't just need to happ= en after the build is complete, but also after Emacs is installed, because = comp-el-to-eln-rel-filename refuses to use native compilation artifacts tha= t were produced before Emacs was installed, because of its strict filename = checking.=C2=A0 Except that it has a special exception for .el files shippe= d with Emacs, which could be extended to site-lisp.
=
And you haven't explained many other = aspects.
Which you don't need to do if you implement your own local solution
for your local problem, but without which you cannot expect us to
suggest the solution of the problem for you.

My point is that I don't see a need for the Emacs upstream project to support AOT native compilation of site-lisp files, because files in
site-lisp are by definition the responsibility of a site.=C2=A0 The Emacs project is not obliged to accommodate every single quirk of every
downstream distribution.=C2=A0 We provide the tools and the source code for=
you to use and change as you see fit, and I see several possible
avenues of approach for this issue that you could have taken for
solving your problem locally.=C2=A0 But for some reason, you reject all the=
proposals, and insist on having something in upstream Emacs.

> I can indeed locally patch comp-el-to-eln-rel-filename to ignore
> part of the filename for files under PATH_SITELOADSEARCH, and that'= ;s
> my current plan, if you think this is reasonable.

I don't think it's reasonable, but it's your distribution and y= our
users you are putting at risk.

Why isn't it reasonable?=C2=A0 Andrea has= previously commented in other bugs that the file name check is not very im= portant in the first place; it's not about correctness, it's just a= convenience for avoiding conflicts during parallel compilation.=C2=A0 Hone= stly the file name check could probably be removed entirely, as it has alre= ady been weakened in other bugs.
--000000000000a362260639906335-- From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2025 13:05:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175215269114104 (code B ref 78783); Thu, 10 Jul 2025 13:05:03 +0000 Received: (at 78783) by debbugs.gnu.org; 10 Jul 2025 13:04:51 +0000 Received: from localhost ([127.0.0.1]:56382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZqxD-0003eq-FZ for submit@debbugs.gnu.org; Thu, 10 Jul 2025 09:04:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57044) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZqx9-0003dK-Dw for 78783@debbugs.gnu.org; Thu, 10 Jul 2025 09:04:45 -0400 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 1uZqx3-0000yW-HU; Thu, 10 Jul 2025 09:04:37 -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=CTV/BdFMi5WjB9KthgqmmzYU8fmsDqnDuP36PnRLLCg=; b=rwQfsEZ/aS4K a5GqDQIo6CLOx3g+NkBkbXmc1K9YCaAnrJPg+9ivn/pHgMQxejq7sywFZ7Mrfth1IC8Oetrr92oFA RsXoDOT+Zz+B5bNBfQaWx8oRzr2zGsOtH4Z7aWo7XIMDQuateFUeUo4ihjHFVUAgdZc0k5AWoaJo+ x7C2O1eT8fdst741xdtBOy97wO/skFtXxMdusjQpznPpyBBgAU8EHc75DR2aIDI7UYXmI8AxT0PKf /wmL28hAsOqqncg3JFN4ZqXQatADUKMO9F90GEToj2VhwFKJfzT6B0ULiQyBqsoTcoHsMiPAHcVzi Wrn7X7RevNpqa89vx7K4oQ==; Date: Thu, 10 Jul 2025 16:04:23 +0300 Message-Id: <86qzyogpt4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 10 Jul 2025 06:09:20 -0400) References: <867c1felht.fsf@gnu.org> <86h60jtu70.fsf@gnu.org> <86tt3lindj.fsf@gnu.org> <86ldoxii6r.fsf@gnu.org> <86jz4hicoa.fsf@gnu.org> <86cya9i7vo.fsf@gnu.org> <867c0gir92.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Thu, 10 Jul 2025 06:09:20 -0400 > Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, > app-emacs-dev > > You haven't explained why you cannot natively-compile the > files after the build is complete, directing the *.eln files to some > shared directory, and package those *.eln files together with the rest > of the built Emacs. > > Because the native compilation doesn't just need to happen after the build is complete, but also after Emacs > is installed, because comp-el-to-eln-rel-filename refuses to use native compilation artifacts that were > produced before Emacs was installed, because of its strict filename checking. Except that it has a special > exception for .el files shipped with Emacs, which could be extended to site-lisp. I don't understand what you are saying. I feel there's a misunderstanding here. My suggestion above was to natively-compile those files _after_ you run "make install", directing the *.eln files to the same directory where the Emacs installation places the*.eln files produced by the build. > > I can indeed locally patch comp-el-to-eln-rel-filename to ignore > > part of the filename for files under PATH_SITELOADSEARCH, and that's > > my current plan, if you think this is reasonable. > > I don't think it's reasonable, but it's your distribution and your > users you are putting at risk. > > Why isn't it reasonable? Andrea has previously commented in other bugs that the file name check is not > very important in the first place; it's not about correctness, it's just a convenience for avoiding conflicts > during parallel compilation. Honestly the file name check could probably be removed entirely, as it has > already been weakened in other bugs. That check is to minimize the risk of loading incompatible *.eln files. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jul 2025 21:13:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: app-emacs-dev@janestreet.com, 78783@debbugs.gnu.org Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.17521819285707 (code B ref 78783); Thu, 10 Jul 2025 21:13:04 +0000 Received: (at 78783) by debbugs.gnu.org; 10 Jul 2025 21:12:08 +0000 Received: from localhost ([127.0.0.1]:60057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uZyYo-0001Tj-QO for submit@debbugs.gnu.org; Thu, 10 Jul 2025 17:12:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33154) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uZyYl-0001Rc-7O for 78783@debbugs.gnu.org; Thu, 10 Jul 2025 17:12:05 -0400 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 1uZyYf-0006kg-4F; Thu, 10 Jul 2025 17:11:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=cgL1T+pAAdYIdzyuBBXhTHoBLeZ5yiwRjMhPL6zYNoM=; b=eQpqWHcvW1YS7joSe4uS pw/ZpadLtTs9lr8IouhE3y81qt2vi4VSRfm3xktBU0bPzNakSeMscEcOImeHj0QKZIVsraGIba4gT e14QFi9Kc9k8ZvwgaipZYINhR9cWMqjlh1rlY8Iguh7cbmfEwAZl7j6dL4ThDL7pU0j5pAYNvGeEI QbxtFr3Xg2OFfyJxkR0VsmVsG2eUT9yYyaQJiKIil7GsRUY6qtcTQ7mQmggjUgGdUwqioLzeHlgbB l8iE0MhaRSEqCLGHc/oOycu8/0TCUAlJEsdtBFPKn1ze50HkyaE2kkMQDfOUom/04TIuV4U9ofTgG Lsa4hkYhZqM2QQ==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1uZyYe-0004Wo-Lk; Thu, 10 Jul 2025 17:11:56 -0400 From: Andrea Corallo In-Reply-To: (Spencer Baugh's message of "Fri, 13 Jun 2025 09:34:10 -0400") References: Date: Thu, 10 Jul 2025 17:11:56 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Spencer Baugh writes: > Native compilation of site-lisp directories during the Emacs build > (e.g. --with-native-compilation=aot) produces .eln files which are > unused when installed. > > The reason is that the absolute file name of the site-lisp directory > differs between build-time and install-time, and therefore > comp-el-to-eln-rel-filename computes a different path hash for the files > contained in site-lisp at build-time and at install-time. > > The same issue would affect AOT native compilation of all Lisp in Emacs, > except that there's a workaround built into comp-el-to-eln-rel-filename, > as explained by this comment: > > As installing .eln files compiled during the build changes their > absolute path we need an hashing mechanism that is not sensitive > to that. For this we replace if match PATH_DUMPLOADSEARCH or > *PATH_REL_LOADSEARCH with '//' before computing the hash. > > In other words, file names containing e.g. "30.1.50/lisp", like > "/usr/local/share/emacs/30.1.50/lisp/foo.el", are transformed to > "//foo.el" before the path hash is computed. > > I suggest the same should be done for file names containing > "30.1.50/site-lisp". That would resolve the problem and allow site-lisp > to actually be AOT-compiled. Mmmmh I don't think it would work as AFAIU not all distros embed the version in the path: https://fedoraproject.org/wiki/QA%3ATestcase_emacs_filesystem https://build.opensuse.org/projects/editors/packages/emacs/files/macros.emacs?expand=0& Andrea From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jul 2025 21:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: app-emacs-dev@janestreet.com, 78783@debbugs.gnu.org Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.1752270081406 (code B ref 78783); Fri, 11 Jul 2025 21:42:01 +0000 Received: (at 78783) by debbugs.gnu.org; 11 Jul 2025 21:41:21 +0000 Received: from localhost ([127.0.0.1]:40718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uaLUe-00006R-9D for submit@debbugs.gnu.org; Fri, 11 Jul 2025 17:41:20 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:47873) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uaLUY-00005v-Fw for 78783@debbugs.gnu.org; Fri, 11 Jul 2025 17:41:18 -0400 Received: from mail-ej1-f70.google.com ([209.85.218.70]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uaLUT-00000002beE-1w1V for 78783@debbugs.gnu.org; Fri, 11 Jul 2025 17:41:09 -0400 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-adb33457610so302064366b.3 for <78783@debbugs.gnu.org>; Fri, 11 Jul 2025 14:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1752270068; x=1752874868; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yc7MrDMaCG8UNsiOr9OpB8iNAX2yj4fBETBFRq93zHA=; b=MM1oHb9qcos+zmFWwQ97t9X9F9yZjgZo+olAxwW4FzYoPK6Qvl4PSu/LQJDalj8WFL ajQR2pJ+LUM14s8Fe5UqEu6TWEJEYc0Nhx/FQzQTyYeAlEKY3cWxIqPU8jhxqG+YcOjG FK0yAyhxy4ON9cacNPMfOZ6Q9WXS0iGW5O5ws= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1752270069; bh=yc7MrDMaCG8UNsiOr9OpB8iNAX2yj4fBETBFRq93zHA=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=ttpgOjBzOx0mAFzxQjfZoobpcwjX7DHugfAp8WN39khxdjsX/dkPkjkK4uY+YP1eW 8W6Tg7HRQwHDHx2RdZ/FuFbCVaYQu9qedkm5vjMBmxUefygl5lQmy3788y+FglYnQF U2uH8mBW/cFDDBTJ2jpYAXYC80btRmoFKC3GlykF6he1gOwECFqgt4Nvm2QEYi9XiX r/feVEOVATgGeCH0KJkC8VJyQ8Ftmk9/N6YPv6a72PUsupxXiavrrDfSYpk0+X/br4 tHfObZOme9k9yfSyqVCxpyjrwbVEPWw0n9lMhEKnT9UMh0IJKgkICTl8tzU+CIpjqO 20ExuMUgY6q9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752270068; x=1752874868; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yc7MrDMaCG8UNsiOr9OpB8iNAX2yj4fBETBFRq93zHA=; b=UedDcDRh5GI1REEuVIzQsBi5qaSY8sjcabdma1p/ewE6h4qnB3IwupjQGpDdST6mPP VFmfHeFirEyhOQZHfWPt+CDsaDkEiGS8QMlGdG69qoqjx2kYUyGsSp6dAVDAJc5mKtM6 RMmAQeBwN1nApcWV85gBZlZLG+RP3D6/Uz24U1vunF6JGDTsJKHgWYzXxIkHYNNAAohW cv+uuwBIfV+HLuouCu7alAKf+OV4NYD9L7hRHzUSi1T/vF2PRVu1MiIE3VAc1XY4To04 XHxZ8jkII1S4f+pBcUHnqBlvSi7Qfu69Gb7sjkoWVxJOiJYVhUwj0qKErFrnJU73//2F w4NQ== X-Gm-Message-State: AOJu0YzojI+WAyMWTOsZKce27oUV1WrnUin1odwp9NMFc1RZhIkx+SRf TKMSlon/4lpkys4d4gyFGBymNGZjI63meSeM77820R7JkPlXEcx0U8ENBVcRe5trwfsIhjM2fyH wwZaUIiJMKULFfR+bqItd2t8nbW1znUWbSjG1gFHh7jzNv/Vy5n9MzPju4/bpDw7wWk+x3an4Nh kUXviH6/6dKeXee9DAv2wa6s2AhMFv/w== X-Gm-Gg: ASbGncuUDXcGf7dA8l5Iww5vm+2vjYt3zj2EqyvaLlXPAIg/+n78KRT2W2+2bgJFrw4 kGzEi5XBfjjUGpBE8zoW0rDYC0jv6WVHIOQyRvJ1L9Tq18LErZnqKfUp4BC5UAq9RCpOV06xGpj 6xt3X+mcdzMwKJ7VLeJlx7 X-Received: by 2002:a17:907:1b26:b0:ade:4593:d7cd with SMTP id a640c23a62f3a-ae6fca442f9mr500099066b.13.1752270065827; Fri, 11 Jul 2025 14:41:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPoYNxtzPFIonTIp9aXXNNIpvcz5CUj2h7gR3cVzFGR+Mkoh5UhD3krESbSwMvQQTFW66zZCO3FPnMiJ/2iJs= X-Received: by 2002:a17:907:1b26:b0:ade:4593:d7cd with SMTP id a640c23a62f3a-ae6fca442f9mr500083166b.13.1752270064653; Fri, 11 Jul 2025 14:41:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Baugh Date: Fri, 11 Jul 2025 17:40:53 -0400 X-Gm-Features: Ac12FXyAFBWVADjjyVIHxNAqB1T8OZkN36LEPtQFDiurmVcpNymCS2MTNo7ex1Q Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Thu, Jul 10, 2025 at 5:11=E2=80=AFPM Andrea Corallo w= rote: > > Spencer Baugh writes: > > > Native compilation of site-lisp directories during the Emacs build > > (e.g. --with-native-compilation=3Daot) produces .eln files which are > > unused when installed. > > > > The reason is that the absolute file name of the site-lisp directory > > differs between build-time and install-time, and therefore > > comp-el-to-eln-rel-filename computes a different path hash for the file= s > > contained in site-lisp at build-time and at install-time. > > > > The same issue would affect AOT native compilation of all Lisp in Emacs= , > > except that there's a workaround built into comp-el-to-eln-rel-filename= , > > as explained by this comment: > > > > As installing .eln files compiled during the build changes their > > absolute path we need an hashing mechanism that is not sensitive > > to that. For this we replace if match PATH_DUMPLOADSEARCH or > > *PATH_REL_LOADSEARCH with '//' before computing the hash. > > > > In other words, file names containing e.g. "30.1.50/lisp", like > > "/usr/local/share/emacs/30.1.50/lisp/foo.el", are transformed to > > "//foo.el" before the path hash is computed. > > > > I suggest the same should be done for file names containing > > "30.1.50/site-lisp". That would resolve the problem and allow site-lis= p > > to actually be AOT-compiled. > > Mmmmh I don't think it would work as AFAIU not all distros embed the > version in the path: > > https://fedoraproject.org/wiki/QA%3ATestcase_emacs_filesystem > > https://build.opensuse.org/projects/editors/packages/emacs/files/macros.e= macs?expand=3D0& Yes, I concretely am suggesting we look at PATH_SITELOADSEARCH so we respect whatever the distro has ./configure'd, not just hardcode "30.1.50/site-lisp". That would allow any distro to ship code in site-lisp and also ship pre-compiled .elns for that code, without having to perform native compilation *after* this installation, which is generally much easier. Thanks for looking at this. From unknown Thu Sep 18 20:48:48 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Jul 2025 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: acorallo@gnu.org, 78783@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78783-submit@debbugs.gnu.org id=B78783.175230152714136 (code B ref 78783); Sat, 12 Jul 2025 06:26:02 +0000 Received: (at 78783) by debbugs.gnu.org; 12 Jul 2025 06:25:27 +0000 Received: from localhost ([127.0.0.1]:43041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uaTfr-0003fw-AK for submit@debbugs.gnu.org; Sat, 12 Jul 2025 02:25:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59438) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uaTfo-0003fL-PK for 78783@debbugs.gnu.org; Sat, 12 Jul 2025 02:25:25 -0400 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 1uaTfj-0006Wf-60; Sat, 12 Jul 2025 02:25:19 -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=NifUYVEl0LLU+g1Zp2CixqE3EFx1/V4MEPHxyJjBTcc=; b=fOw8G4GWEOUF eAJ73CNChRPlQMouhAGVPD6vUTS4scoI2fgsFSiu3W3JEJJ1qMW/D+m2YFMI/TpqAPGen2a/y44O+ hvOmSq86L6qMw3aWFGiQQuKKYfNsXnk5i8exHTiEYHnGPB2NrLdE4F7u5IDmZTqI7aS61iqUCOxP+ I0ctLd085r6hnDF8+1Au4VOkdsmNg3K7KLrRXRYmd8q4b2Bq67XhOR3yO6iiOCqzhEe5UEtpdynuq hZNs7Ka4dB7M2l7+SumOhFcfetpUv+lrI+4OIIGKYM8RgkkcHTu21+TUwGfjPeT9hullFQ0SKtlvd 9PYzRPuh2hq4UTqZpgt6tw==; Date: Sat, 12 Jul 2025 09:25:13 +0300 Message-Id: <86tt3iexiu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: app-emacs-dev@janestreet.com, 78783@debbugs.gnu.org > Date: Fri, 11 Jul 2025 17:40:53 -0400 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Yes, I concretely am suggesting we look at PATH_SITELOADSEARCH so we > respect whatever the distro has ./configure'd, not just hardcode > "30.1.50/site-lisp". > > That would allow any distro to ship code in site-lisp and also ship > pre-compiled .elns for that code, without having to perform native > compilation *after* this installation, which is generally much easier. I'm against such a change, since you could solve your problem without it. I'm not interested in complicating our startup code and its subtleties (of which there are already too many) because you have a local problem that can be solved within the current restrictions, sorry.