From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 15:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 74382@debbugs.gnu.org Cc: Alan Mackenzie X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.173176988030748 (code B ref -1); Sat, 16 Nov 2024 15:12:02 +0000 Received: (at submit) by debbugs.gnu.org; 16 Nov 2024 15:11:20 +0000 Received: from localhost ([127.0.0.1]:54343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCKSG-0007zs-BB for submit@debbugs.gnu.org; Sat, 16 Nov 2024 10:11:20 -0500 Received: from lists.gnu.org ([209.51.188.17]:38510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCKSC-0007zi-3V for submit@debbugs.gnu.org; Sat, 16 Nov 2024 10:11:18 -0500 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 1tCKSB-0004Se-2P for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 10:11:15 -0500 Received: from forward100b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d100]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tCKS8-0001Hw-A8 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 10:11:14 -0500 Received: from mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:18aa:0:640:5723:0]) by forward100b.mail.yandex.net (Yandex) with ESMTPS id 717D060D1E; Sat, 16 Nov 2024 18:11:03 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 2BQOnoKOdCg0-UfhnlZZr; Sat, 16 Nov 2024 18:11:02 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731769863; bh=pil43Wrexx6kdt3rM6HaggCczjQAXL6rduH8BJEsEIw=; h=Date:Cc:To:From:Subject:Message-ID; b=epJV95KIzm/y5prCNTqcjOMe4ya0EGwmdMBmiBvV+zHm3VDpsj47Y1Si3CI+Qlhft vQw7otMpPi/YdoKkpV55KpZ3nhcvNTWYDdzxINdVKJ6MOxHNpPDS8KkXDbXpu0NQJ8 MEeENk0mDftdokg7Xq7g+oaoV3nkqsBSuGr7aH6I= Authentication-Results: mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> From: Konstantin Kharlamov Date: Sat, 16 Nov 2024 18:11:01 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 Received-SPF: pass client-ip=2a02:6b8:c02:900:1:45:d181:d100; envelope-from=Hi-Angel@yandex.ru; helo=forward100b.mail.yandex.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.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: -2.3 (--) CC: Alan Mackenzie, author of the change in 10083e788f7349fa363d100687dc3d9= 4bea88f57 I've seen for a long time Emacs master builds fail from time to time in spe= ctacular ways after updating the repo, sometimes so badly that `make clean` doesn't = help. I never dug into that though, but I'm attributing this to the occasional bu= ild messages similar to: Source file =E2=80=98/home/constantine/Projects/emacs/lisp/emacs-lisp/c= omp.el=E2=80=99 newer than byte-compiled file; using older file Source file =E2=80=98/home/constantine/Projects/emacs/lisp/emacs-lisp/b= ytecomp.el=E2=80=99 newer than byte-compiled file; using older file Source file =E2=80=98/home/constantine/Projects/emacs/lisp/emacs-lisp/c= omp-cstr.el=E2=80=99 newer than byte-compiled file; using older file =E2=80=A6which makes sense, because if the repo changed `comp.el` API and E= macs during the build of newer files is trying to make use of older `.elc` file and hence t= he older API, it may result in failure. Got some spare time today, dug into one of the messages. From what I unders= tand it's caused by this line `lisp/Makefile.in`: # ... but we must prefer .elc files for those in the early bootstrap. compile-first: BYTE_COMPILE_FLAGS =3D $(BYTE_COMPILE_EXTRA_FLAGS) >From what I understand, this rewrites BYTE_COMPILE_FLAGS to be an empty var= iable, which results in `(setq load-prefer-newer t)` being stripped off of the bui= ld. The straightforward solution is to remove this line. But since the line's c= ommentary opposes to such solution, I'm starting up a discussion what exactly should = be the behavior here =F0=9F=98=8A From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173177444812389 (code B ref 74382); Sat, 16 Nov 2024 16:28:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 16:27:28 +0000 Received: from localhost ([127.0.0.1]:54492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCLdv-0003Dk-Ml for submit@debbugs.gnu.org; Sat, 16 Nov 2024 11:27:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCLdt-0003DU-AW for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 11:27:26 -0500 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 1tCLdl-00051C-6d; Sat, 16 Nov 2024 11:27:17 -0500 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=OnZh1KzOsb3cQFd75mXlwVi2UJxMskkhLxe02ZMxAuM=; b=LrfukZJt420Ljzu43Syr gd9iOvrvf0o/H3EmWU54p3B7lemhxSZj439mY3BZJBHjR4KQuFbYh17kdZ/G6FwENv8wC34TNyI7S mR/W+gfzLSO8GszNMTEHZgO3p1bZuyyZt93j0RYsf7vHai7loSM0yCNlbu9zOVHHsWN/NvO8qClZS mBj8ghZgZK5lEp4KPI4eNPWRvKFeQ96GXcnVqoRJ3poCYyyv6ymecXRW7f5jDDpJh+8Ba8P6+AbXu syLfogFEcAUrnh82GX4GplSSL6Y6LYAPapLyTcCciJhwEtkeBu6rLy4GN7Nv9L+OqgkiXZhAE2h3R uNwEPXdkesW9Ig==; Date: Sat, 16 Nov 2024 18:27:14 +0200 Message-Id: <86y11jf8kd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> (message from Konstantin Kharlamov on Sat, 16 Nov 2024 18:11:01 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> 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 (---) > Cc: Alan Mackenzie > From: Konstantin Kharlamov > Date: Sat, 16 Nov 2024 18:11:01 +0300 > > CC: Alan Mackenzie, author of the change in 10083e788f7349fa363d100687dc3d94bea88f57 > > I've seen for a long time Emacs master builds fail from time to time in spectacular > ways after updating the repo, sometimes so badly that `make clean` doesn't help. > > I never dug into that though, but I'm attributing this to the occasional build > messages similar to: > > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp.el’ newer than byte-compiled file; using older file > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/bytecomp.el’ newer than byte-compiled file; using older file > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp-cstr.el’ newer than byte-compiled file; using older file > > …which makes sense, because if the repo changed `comp.el` API and Emacs during the > build of newer files is trying to make use of older `.elc` file and hence the older > API, it may result in failure. > > Got some spare time today, dug into one of the messages. From what I understand it's > caused by this line `lisp/Makefile.in`: > > # ... but we must prefer .elc files for those in the early bootstrap. > compile-first: BYTE_COMPILE_FLAGS = $(BYTE_COMPILE_EXTRA_FLAGS) > > >From what I understand, this rewrites BYTE_COMPILE_FLAGS to be an empty variable, > which results in `(setq load-prefer-newer t)` being stripped off of the build. They are supposed to be stripped only while processing the compile-first target, and that is on purpose. See the section "Target-specific" in the GNU Make manual, where this feature is documented. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 16:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173177603317037 (code B ref 74382); Sat, 16 Nov 2024 16:54:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 16:53:53 +0000 Received: from localhost ([127.0.0.1]:54573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCM3U-0004Qj-PN for submit@debbugs.gnu.org; Sat, 16 Nov 2024 11:53:53 -0500 Received: from mail.muc.de ([193.149.48.3]:31610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCM3S-0004QU-9W for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 11:53:51 -0500 Received: (qmail 45405 invoked by uid 3782); 16 Nov 2024 17:53:43 +0100 Received: from muc.de (p4fe151f0.dip0.t-ipconnect.de [79.225.81.240]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 16 Nov 2024 17:53:43 +0100 Received: (qmail 10848 invoked by uid 1000); 16 Nov 2024 16:53:42 -0000 Date: Sat, 16 Nov 2024 16:53:42 +0000 Message-ID: References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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: -1.0 (-) Hello, Konstantin. On Sat, Nov 16, 2024 at 18:11:01 +0300, Konstantin Kharlamov wrote: > CC: Alan Mackenzie, author of the change in 10083e788f7349fa363d100687dc3d94bea88f57 > I've seen for a long time Emacs master builds fail from time to time in spectacular > ways after updating the repo, sometimes so badly that `make clean` doesn't help. > I never dug into that though, but I'm attributing this to the occasional build > messages similar to: > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp.el’ newer than byte-compiled file; using older file > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/bytecomp.el’ newer than byte-compiled file; using older file > Source file ‘/home/constantine/Projects/emacs/lisp/emacs-lisp/comp-cstr.el’ newer than byte-compiled file; using older file > …which makes sense, because if the repo changed `comp.el` API and Emacs during the > build of newer files is trying to make use of older `.elc` file and hence the older > API, it may result in failure. The idea is that the byte compiler is first built from .el files, giving ..elc files. The .elc byte compiler is then used for all the other files, since it's much faster. > Got some spare time today, dug into one of the messages. From what I understand it's > caused by this line `lisp/Makefile.in`: > # ... but we must prefer .elc files for those in the early bootstrap. > compile-first: BYTE_COMPILE_FLAGS = $(BYTE_COMPILE_EXTRA_FLAGS) > >From what I understand, this rewrites BYTE_COMPILE_FLAGS to be an empty variable, > which results in `(setq load-prefer-newer t)` being stripped off of the build. Yes, this is to prefer the faster .elc byte compiler, whose file dates have been set back to the epoch (1970-01-01:00:00:00 UTC). I think this was to ensure that when we come to native compilation, the .el source files of the compiler will be newer than the .elc files, hence triggering a native compilation of them. I honestly don't believe that this mechanism for speeding up the early build is the cause of the spectacular failures in some of your builds, but I could be wrong. > The straightforward solution is to remove this line. But since the line's commentary > opposes to such solution, I'm starting up a discussion what exactly should be the > behavior here 😊 Perhaps if you could be more specific about the failures you see, we might be able to be of more help. -- Alan Mackenzie (Nuremberg, Germany). From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 17:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173177916326352 (code B ref 74382); Sat, 16 Nov 2024 17:47:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 17:46:03 +0000 Received: from localhost ([127.0.0.1]:54695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCMrz-0006qx-69 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 12:46:03 -0500 Received: from forward502b.mail.yandex.net ([178.154.239.146]:33506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCMrv-0006qD-8f for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 12:46:01 -0500 Received: from mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:18aa:0:640:5723:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 74E306116F; Sat, 16 Nov 2024 20:45:50 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id mjSAd2MOdOs0-zeP1oTg8; Sat, 16 Nov 2024 20:45:50 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731779150; bh=NwMkyhB4EKBd16yTjP6M/qYrSYJ8I23wUdfoPYEa8Kg=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=bngocX1gN2jMkz8s4OpEL8uycp+h0LSoPQgBhul0B5tTnp0Ne2kYscFtZsM5pviiL TfnuzO2nmtUICSQWZ4I9D+NC2LmjNWAakNNDKZJnxjHwnBXjf06S4AipuG6gwk4AgT zVo/EoCrQD3ANyu5D5w+b7FOzW8r6Rur+ur4Vlvo= Authentication-Results: mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Konstantin Kharlamov Date: Sat, 16 Nov 2024 20:45:47 +0300 In-Reply-To: References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Sat, 2024-11-16 at 16:53 +0000, Alan Mackenzie wrote: > Hello, Konstantin. > > On Sat, Nov 16, 2024 at 18:11:01 +0300, Konstantin Kharlamov wrote: > > CC: Alan Mackenzie, author of the change in > > 10083e788f7349fa363d100687dc3d94bea88f57 > > > I've seen for a long time Emacs master builds fail from time to > > time in spectacular > > ways after updating the repo, sometimes so badly that `make clean` > > doesn't help. > > > I never dug into that though, but I'm attributing this to the > > occasional build > > messages similar to: > > > =C2=A0=C2=A0=C2=A0 Source file =E2=80=98/home/constantine/Projects/emac= s/lisp/emacs- > > lisp/comp.el=E2=80=99 newer than byte-compiled file; using older file > > =C2=A0=C2=A0=C2=A0 Source file =E2=80=98/home/constantine/Projects/emac= s/lisp/emacs- > > lisp/bytecomp.el=E2=80=99 newer than byte-compiled file; using older fi= le > > =C2=A0=C2=A0=C2=A0 Source file =E2=80=98/home/constantine/Projects/emac= s/lisp/emacs- > > lisp/comp-cstr.el=E2=80=99 newer than byte-compiled file; using older f= ile > > > =E2=80=A6which makes sense, because if the repo changed `comp.el` API a= nd > > Emacs during the > > build of newer files is trying to make use of older `.elc` file and > > hence the older > > API, it may result in failure. > > The idea is that the byte compiler is first built from .el files, > giving > ..elc files.=C2=A0 The .elc byte compiler is then used for all the other > files, since it's much faster. > > > Got some spare time today, dug into one of the messages. From what > > I understand it's > > caused by this line `lisp/Makefile.in`: > > > =C2=A0=C2=A0=C2=A0 # ... but we must prefer .elc files for those in the= early > > bootstrap. > > =C2=A0=C2=A0=C2=A0 compile-first: BYTE_COMPILE_FLAGS =3D $(BYTE_COMPILE= _EXTRA_FLAGS) > > > > From what I understand, this rewrites BYTE_COMPILE_FLAGS to be an > > > empty variable, > > which results in `(setq load-prefer-newer t)` being stripped off of > > the build. > > Yes, this is to prefer the faster .elc byte compiler, whose file > dates > have been set back to the epoch (1970-01-01:00:00:00 UTC).=C2=A0 I think > this > was to ensure that when we come to native compilation, the .el source > files of the compiler will be newer than the .elc files, hence > triggering a native compilation of them. > > I honestly don't believe that this mechanism for speeding up the > early > build is the cause of the spectacular failures in some of your > builds, > but I could be wrong. > > > The straightforward solution is to remove this line. But since the > > line's commentary > > opposes to such solution, I'm starting up a discussion what exactly > > should be the > > behavior here =F0=9F=98=8A > > Perhaps if you could be more specific about the failures you see, we > might be able to be of more help. Sure, I just reproduced it after removing all `.elc` files in the repo, here how: 1. `git checkout f2f13fa630b` (a commit from April) 2. `make -j$(nproc)` to compile. Note: you don't need to wait for build to finish, I just waited for all files under `lisp/emacs-lisp` directory to finish compilation, and then ^C'ed it. 3. `git checkout 29098a291f5` (a November commit). 4. `make -j$(nproc)` ## Expected Build finishes ## Actual It fails with stacktrace so huge that it goes beyond Konsole scrollback and with the following message: Loading macroexp.elc (compiled; note, source file is newer)... Wrong type argument: "../../lisp/emacs-lisp/comp.el", hash-table-p, (#s= (byte-to-native-top-level (byte-code "=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD= =EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD!=EF=BF=BD= =EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD!= =EF=BF=BD=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD%=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDDD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD& =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BDDD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD& =EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BDDD=EF=BF=BD=EF=BF=BD=EF=BF=BD&=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BDDD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD&= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDDD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD&=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BDDD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD&=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDDD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD&=EF=BF=BD" [require bytecomp cl-lib gv rx subr-x warnings comp-co= mmon comp-cstr custom-declare-group ...] 10) t) #s(byte-to-native-top-level= (# # nil "Non-nil= to prevent native-compiling of Emacs Lisp code. Note that when `no-byte-compile' is set to non-nil it overrides the val= ue of `no-native-compile'. This is normally set in local file variables at the end of the Emacs Lisp file: You can see it fails on the `comp.el`, and I presume the reason is it simpl= y didn't rebuild the necessary .elc files, and instead loaded outdated byte= code. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17317823412755 (code B ref 74382); Sat, 16 Nov 2024 18:39:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 18:39:01 +0000 Received: from localhost ([127.0.0.1]:54771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNhF-0000iN-66 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 13:39:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNhD-0000iB-N8 for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 13:39:00 -0500 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 1tCNh7-0005iR-PW; Sat, 16 Nov 2024 13:38:53 -0500 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=bXbW69RsyL1GwlBnh+neJZu0gK7DPR4Vcs+Ha5ef2hw=; b=Mg37X/STVn8g62WMuub9 U7j6zmeT34uI6fUulicwbxbYssqV+4r/zwDIaOdmQiag/J5NugSWWyYFcnVBtO5faNUoWStdD5PBM 3lR2GD2N89YHhvZ2cgfzCWcWD1fq7tJKrPxGuygMXnlf3ohyTcoKR4Kt+58AMNrgNwe82sUEmUeaO y0l0qHmmiHpZHHaO9X/K/rTa4PTVhu9sMltGnQ6FaAGdQf5eUtaMzAPPjSktCUoLNYVa7T0rWdPep /V6txkTBr+wfQvQYKQuEsOHS5E4lZFE1MfLit51uYa/8V6IGsKlUYbd6vU8f8nHZ3wyYMEk2EIjdb 09qiIIQjOkENkA==; Date: Sat, 16 Nov 2024 20:38:51 +0200 Message-Id: <86o72ff2h0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Konstantin Kharlamov on Sat, 16 Nov 2024 20:45:47 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> 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 (---) > Cc: 74382@debbugs.gnu.org > From: Konstantin Kharlamov > Date: Sat, 16 Nov 2024 20:45:47 +0300 > > ## Expected > > Build finishes > > ## Actual > > It fails with stacktrace so huge that it goes beyond Konsole scrollback > and with the following message: > > > Loading macroexp.elc (compiled; note, source file is newer)... > Wrong type argument: "../../lisp/emacs-lisp/comp.el", hash-table-p, (#s(byte-to-native-top-level (byte-code "��!���!���!���!���!���!���!���!������%�����DD�����& �����DD�����& �����DD���&�����DD�����&������DD�����&������DD�����&������DD�����&�" [require bytecomp cl-lib gv rx subr-x warnings comp-common comp-cstr custom-declare-group ...] 10) t) #s(byte-to-native-top-level (# # nil "Non-nil to prevent native-compiling of Emacs Lisp code. > Note that when `no-byte-compile' is set to non-nil it overrides the value of > `no-native-compile'. > This is normally set in local file variables at the end of the > Emacs Lisp file: I don't think this is related to what lisp/Makefile does. When macroexp.el is updated, builds are known to fail until you remove macroexp.elc (or bootstrap). From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 18:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17317826323597 (code B ref 74382); Sat, 16 Nov 2024 18:44:01 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 18:43:52 +0000 Received: from localhost ([127.0.0.1]:54785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNlw-0000vw-8V for submit@debbugs.gnu.org; Sat, 16 Nov 2024 13:43:52 -0500 Received: from forward500d.mail.yandex.net ([178.154.239.208]:40558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNlu-0000vd-2F for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 13:43:51 -0500 Received: from mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:179e:0:640:81cc:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id 68BE460F8A; Sat, 16 Nov 2024 21:43:44 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id ghTasvEOrSw0-p83sakfJ; Sat, 16 Nov 2024 21:43:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731782623; bh=u7d6TW09GcDUXcUVksICeBhqQzPGqhEkSM/Sf+qUmgk=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=RHkVn4GbfIOax60VBhYRb0enkXS8QlnLmFU1CeSgNzZgmLI8ou04AYX49pMgJYgBG DfxZo189f1bG3/evJQJi+1l6Q42wtfseL89A2mXq+3xLUgiFmnpiSgOjrzwcXJNSqs lZMDUq4eWAjgL24w7oMr/8+ufeRZ4uRAF/LbxYIQ= Authentication-Results: mail-nwsmtp-smtp-production-main-18.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> From: Konstantin Kharlamov Date: Sat, 16 Nov 2024 21:43:41 +0300 In-Reply-To: <86o72ff2h0.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86o72ff2h0.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 User-Agent: Evolution 3.54.1 MIME-Version: 1.0 X-Spam-Score: -0.7 (/) 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: -1.7 (-) T24gU2F0LCAyMDI0LTExLTE2IGF0IDIwOjM4ICswMjAwLCBFbGkgWmFyZXRza2lpIHdyb3RlOgo+ ID4gQ2M6IDc0MzgyQGRlYmJ1Z3MuZ251Lm9yZwo+ID4gRnJvbTogS29uc3RhbnRpbiBLaGFybGFt b3YgPEhpLUFuZ2VsQHlhbmRleC5ydT4KPiA+IERhdGU6IFNhdCwgMTYgTm92IDIwMjQgMjA6NDU6 NDcgKzAzMDAKPiA+IAo+ID4gIyMgRXhwZWN0ZWQKPiA+IAo+ID4gQnVpbGQgZmluaXNoZXMKPiA+ IAo+ID4gIyMgQWN0dWFsCj4gPiAKPiA+IEl0IGZhaWxzIHdpdGggc3RhY2t0cmFjZSBzbyBodWdl IHRoYXQgaXQgZ29lcyBiZXlvbmQgS29uc29sZQo+ID4gc2Nyb2xsYmFjawo+ID4gYW5kIHdpdGgg dGhlIGZvbGxvd2luZyBtZXNzYWdlOgo+ID4gCj4gPiAKPiA+IMKgwqDCoCBMb2FkaW5nIG1hY3Jv ZXhwLmVsYyAoY29tcGlsZWQ7IG5vdGUsIHNvdXJjZSBmaWxlIGlzIG5ld2VyKS4uLgo+ID4gwqDC oMKgIFdyb25nIHR5cGUgYXJndW1lbnQ6ICIuLi8uLi9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCIs IGhhc2gtCj4gPiB0YWJsZS1wLCAoI3MoYnl0ZS10by1uYXRpdmUtdG9wLWxldmVsIChieXRlLWNv ZGUKPiA+ICLvv73vv70h77+977+977+9Ie+/ve+/ve+/vSHvv73vv73vv70h77+977+977+9Ie+/ ve+/ve+/vSHvv73vv73vv70h77+977+977+9Ie+/ve+/ve+/ve+/ve+/ve+/vSXvv73vv73vv73v v73vv71ERO+/ve+/ve+/ve+/ve+/vSbCoMKgwqDCoMKgwqDCoAo+ID4g77+977+977+977+977+9 RETvv73vv73vv73vv73vv70mwqDCoAo+ID4g77+977+977+977+977+9RETvv73vv73vv70m77+9 77+977+977+977+9RETvv73vv73vv73vv73vv70m77+977+977+977+977+977+9RETvv73vv73v v73vv73vv70m77+977+977+977+977+977+9RETvv73vv73vv73vv73vv70m77+977+977+977+9 77+977+9RETvv73vv73vv73vv73vv70m77+9Cj4gPiAiIFtyZXF1aXJlIGJ5dGVjb21wIGNsLWxp YiBndiByeCBzdWJyLXggd2FybmluZ3MgY29tcC1jb21tb24gY29tcC0KPiA+IGNzdHIgY3VzdG9t LWRlY2xhcmUtZ3JvdXAgLi4uXSAxMCkgdCkgI3MoYnl0ZS10by1uYXRpdmUtdG9wLWxldmVsCj4g PiAoIzxzeW1ib2wgZGVmdmFyIGF0IDQ0MjU+ICM8c3ltYm9sIG5vLW5hdGl2ZS1jb21waWxlIGF0 IDQ0MzI+IG5pbAo+ID4gIk5vbi1uaWwgdG8gcHJldmVudCBuYXRpdmUtY29tcGlsaW5nIG9mIEVt YWNzIExpc3AgY29kZS4KPiA+IMKgwqDCoCBOb3RlIHRoYXQgd2hlbiBgbm8tYnl0ZS1jb21waWxl JyBpcyBzZXQgdG8gbm9uLW5pbCBpdCBvdmVycmlkZXMKPiA+IHRoZSB2YWx1ZSBvZgo+ID4gwqDC oMKgIGBuby1uYXRpdmUtY29tcGlsZScuCj4gPiDCoMKgwqAgVGhpcyBpcyBub3JtYWxseSBzZXQg aW4gbG9jYWwgZmlsZSB2YXJpYWJsZXMgYXQgdGhlIGVuZCBvZiB0aGUKPiA+IMKgwqDCoCBFbWFj cyBMaXNwIGZpbGU6Cj4gCj4gSSBkb24ndCB0aGluayB0aGlzIGlzIHJlbGF0ZWQgdG8gd2hhdCBs aXNwL01ha2VmaWxlIGRvZXMuwqAgV2hlbgo+IG1hY3JvZXhwLmVsIGlzIHVwZGF0ZWQsIGJ1aWxk cyBhcmUga25vd24gdG8gZmFpbCB1bnRpbCB5b3UgcmVtb3ZlCj4gbWFjcm9leHAuZWxjIChvciBi b290c3RyYXApLgoKT2theSwgYnV0IHdoeSB5b3UgbmVlZCB0byByZW1vdmUgbWFjcm9leHAuZWxj LCBpc24ndCBpdCB0aGUgYnVpbGQKc3lzdGVtIGpvYiB0byByZWJ1aWxkIGl0IHdoZW4gaXQncyBj aGFuZ2VkPyBJIHRoaW5rIHNvLCBhbmQgdGhlCm1hY3JvZXhwLmVsIGlzIGFtb25nIHRoZSBgQ09N UElMRV9GSVJTVGAgZmlsZXMgaW4gbGlzcC9NYWtlZmlsZS5pbi4K From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 20:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173178741617417 (code B ref 74382); Sat, 16 Nov 2024 20:04:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 20:03:36 +0000 Received: from localhost ([127.0.0.1]:54891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCP16-0004Wr-07 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 15:03:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCP12-0004Wb-IX for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 15:03:34 -0500 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 1tCOyn-00017d-Us; Sat, 16 Nov 2024 15:01:13 -0500 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=U78X4149LrM6lWajhdzr+RW1o9iv3DFfQjhUnEZhYks=; b=KrgECa4V/SQ3UWRURdYM CT1zQyn3vVnhYFEOLeWVwTicp70xjWL8cA+B0emYRPPx7esR+mZYQYj5kLDkHqYgvLZfF6NXdk2JR Df+Oia1MoEjj7jNO17iGm1rHwx/0GxPZ14JKVt9AzFD7Bo7FTRzHY0hS1IiyO/ggY6DJ2aGtn2tUO tHqwRo/rV3gnVlQvqtYuT3400vQUDMGibTsAY2jwQBrII+6GkMWjc/goJ/w5YcZP1hcYkNKbqxVws my02JxP1c4b6irB583Q55n6I5T8N4+p6xkoAnLKj2PD33ibj0HUrX94ou2rnMBIyIDpmTX2r9MpcV pYpjhSNAayhGig==; Date: Sat, 16 Nov 2024 22:00:56 +0200 Message-Id: <86y11jvthj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> (message from Konstantin Kharlamov on Sat, 16 Nov 2024 21:43:41 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86o72ff2h0.fsf@gnu.org> <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> 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 (---) > Cc: acm@muc.de, 74382@debbugs.gnu.org > From: Konstantin Kharlamov > Date: Sat, 16 Nov 2024 21:43:41 +0300 > > > I don't think this is related to what lisp/Makefile does.  When > > macroexp.el is updated, builds are known to fail until you remove > > macroexp.elc (or bootstrap). > > Okay, but why you need to remove macroexp.elc Because macroexp.el contains macros, which might have been already expanded in the .elc file(s). > isn't it the build system job to rebuild it when it's changed? It's impractical, because we have many files with macros. Tracking all of those dependencies would mean that changes in any file will trigger unnecessary recompilation of many other files. If you don't mind spending that time waiting for the build, just "make bootstrap" every time you update from Git, and you will have that. > I think so, and the > macroexp.el is among the `COMPILE_FIRST` files in lisp/Makefile.in. Yes, because it is needed to bootstrap the native-compilation stuff, and using the .el file makes that extremely slow. There's no bug here. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 22:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173179770114866 (code B ref 74382); Sat, 16 Nov 2024 22:55:02 +0000 Received: (at 74382) by debbugs.gnu.org; 16 Nov 2024 22:55:01 +0000 Received: from localhost ([127.0.0.1]:55117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCRgz-0003ra-59 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 17:55:01 -0500 Received: from forward502b.mail.yandex.net ([178.154.239.146]:49940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCRgw-0003rL-Go for 74382@debbugs.gnu.org; Sat, 16 Nov 2024 17:54:59 -0500 Received: from mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:c61f:0:640:7720:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 40E1760F47; Sun, 17 Nov 2024 01:54:50 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id nsXXgROOjGk0-4BgH11DQ; Sun, 17 Nov 2024 01:54:49 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731797689; bh=/Fe2Qvs6Trd7Ibn3vD5TTmE7IFgDyNmyMuwIksuoD9I=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=hbAZBxvDNd6CWjCEC0vHKgA/Rfb/WfzGKqIO5dk6YFWBHuB5mIWiTEduQyfKpshcX E18fWrLOnJGWQas/pUHCdChUyEo2JDSsiM1QKIqW5gdMlkQj1Flt3FOyhlqDqOwOjT aKHQjLhrS0sgMmbTA1I05HA7azKFUBkRzDPu3WX0= Authentication-Results: mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <46a8bf630b89755bd6edc1521390352ecc176881.camel@yandex.ru> From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 01:54:48 +0300 In-Reply-To: <86y11jvthj.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86o72ff2h0.fsf@gnu.org> <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> <86y11jvthj.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Sat, 2024-11-16 at 22:00 +0200, Eli Zaretskii wrote: > > Cc: acm@muc.de, 74382@debbugs.gnu.org > > From: Konstantin Kharlamov > > Date: Sat, 16 Nov 2024 21:43:41 +0300 > >=20 > > > I don't think this is related to what lisp/Makefile does.=C2=A0 When > > > macroexp.el is updated, builds are known to fail until you remove > > > macroexp.elc (or bootstrap). > >=20 > > Okay, but why you need to remove macroexp.elc >=20 > Because macroexp.el contains macros, which might have been already > expanded in the .elc file(s). >=20 > > isn't it the build system job to rebuild it when it's changed? >=20 > It's impractical, because we have many files with macros.=C2=A0 Tracking > all of those dependencies would mean that changes in any file will > trigger unnecessary recompilation of many other files.=C2=A0 If you don't > mind spending that time waiting for the build, just "make bootstrap" > every time you update from Git, and you will have that. Unless I'm missing something, the problem seems to be with one exact file, macroexpand.elc, and not with others. So the algorithm is simple: if `macroexpand.el` was modified, remove its elc file. You don't need to track any dependencies. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 06:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.1731825879892 (code B ref 74382); Sun, 17 Nov 2024 06:45:03 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 06:44:39 +0000 Received: from localhost ([127.0.0.1]:55720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCZ1S-0000EF-Gk for submit@debbugs.gnu.org; Sun, 17 Nov 2024 01:44:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCZ1Q-0000Dy-Ph for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 01:44:38 -0500 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 1tCZ1K-0002aL-Te; Sun, 17 Nov 2024 01:44:30 -0500 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=son0cakUIW9PWvhTWrlacQt3JBIz4NsCnwkIaMmbPSU=; b=rwNpWd3iqslyhWJAfAXs y8h77IDB4YsLB+PqvSsSKZ4dLx6wqq/6ZtKIt2FJKPEjYKNCN63MWu2tLwlq80TvWTFAQguv0CzlV DRXCGlk/fq3PhUQlK5HZcj18IvytcFLA64lgiqwE60BoSavUp7bX1mT4eQNm+W0FPaiecxGvjzf4s mowsUm1PHiqWznIQIdXiYHILtOl/Wq/G19fRhNeKgruPNWjlUjwsnCDnVoMF9pKAdkgvMjnpxvat2 FPJKM2nHEE/zPv6wOI8KMDDHBgwdcbbGQ32VKRwK9IK/H4er1mpPQ/tFx8qIwB8DDlEhyUdo5T9SU N07qEAaBLFAJvQ==; Date: Sun, 17 Nov 2024 08:44:26 +0200 Message-Id: <86jzd2we9h.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <46a8bf630b89755bd6edc1521390352ecc176881.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 17 Nov 2024 01:54:48 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86o72ff2h0.fsf@gnu.org> <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> <86y11jvthj.fsf@gnu.org> <46a8bf630b89755bd6edc1521390352ecc176881.camel@yandex.ru> 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: Konstantin Kharlamov > Cc: acm@muc.de, 74382@debbugs.gnu.org > Date: Sun, 17 Nov 2024 01:54:48 +0300 > > > It's impractical, because we have many files with macros.  Tracking > > all of those dependencies would mean that changes in any file will > > trigger unnecessary recompilation of many other files.  If you don't > > mind spending that time waiting for the build, just "make bootstrap" > > every time you update from Git, and you will have that. > > Unless I'm missing something, the problem seems to be with one exact > file, macroexpand.elc, and not with others. No, that's not true. I had similar problems with basically all the files in COMPILE_FIRST. More importantly, what you seem to be missing is that we deliberately play with the time stamps of the *.elc files in COMPILE_FIRST (search for "UTC" in the Makefile), so we must not use load-prefer-newer in this case. That is the reason why it's removed from BYTE_COMPILE_FLAGS. > So the algorithm is simple: if `macroexpand.el` was modified, remove > its elc file. You don't need to track any dependencies. How will load-prefer-newer help if this is what you do? That's the trigger for this bug report, no? In any case, this is not the reason why load-prefer-newer is removed while we COMPILE_FIRST; see above. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 07:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: Alan Mackenzie , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17318283799241 (code B ref 74382); Sun, 17 Nov 2024 07:27:01 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 07:26:19 +0000 Received: from localhost ([127.0.0.1]:55770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCZfn-0002Oz-3k for submit@debbugs.gnu.org; Sun, 17 Nov 2024 02:26:19 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:51510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCZfk-0002Oq-Ao for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 02:26:17 -0500 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3823cae4be1so538547f8f.3 for <74382@debbugs.gnu.org>; Sat, 16 Nov 2024 23:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731828315; x=1732433115; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=cZDRqKASN2VWUE0iMOsYBXi860slY64zZk++gxJIw8E=; b=DL77T1hEaXQH3TmHWZO77iDrzTJVVXBwOLUUiUBaYJXqVriJSeFux6lTInTqf3WoZm jrMOy0qmo6f11YZHVV/Zler2wOpUFI1CSpI/ujC6bUAyuZtifxv1jne5DN/ensnXa1rj 52k0JsgskIkrSsUAOHFhPRGmhYevPClwfdCc8ZsZlgIYoJPsgP7df96cbY+pyzL3Na8m wU6CLkJ3g4f5OKdH+AxQMPDYKbQuZx3qcmJ1wilIcrqdhzW3UzTir0fo3WW1sLt7JQzj Lo2RvTLZ8pWYg7AoSrHijadBEasC/sVU4CBLhiRGJ9VInkk3AO6xP3dT5t5Lo56ZDY2J MnDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731828315; x=1732433115; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cZDRqKASN2VWUE0iMOsYBXi860slY64zZk++gxJIw8E=; b=OwrIeB2XRmHzWmYZglaz4/lkc8Lxk4hVzefFMhMqYt1sAGn2ewmMdiO2qVm8CntNO+ gLH+tSsLW55DyenuzCEHRIKsaxdSRviFX88ZoQCpequjZZT70fc76neA26UPzXQwt2KT niAtq9A/aw9OgA+L07//hwjoKvGAYy8SNj49F2uXg/jKcDbEIcWW9dr2rPkxF6kKWxmi UD6fVBMXV/wYt/qYAQ+um9zhrFCAyFC9xhZ9LdUGedcnJKTHAF8DNwEJkz/mJO83cg4q msaayKiYOVrrdPF4oTnvkx0IF8zI3q+dtqwi9QAO9DOAlIgfb/YMsCLd+AbZNblI1Bh9 3tzA== X-Forwarded-Encrypted: i=1; AJvYcCXCEqA3xV5cPo/S1O5VgrBfYkXmCCWqUj106N+Rk+O+zndLIcaMtiR1LRBAJ0skKyAMDWkgtQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxd0eAmy7l2mj5rG9s70UNTeEw2oOdsb0oLr/zHAO/JAjdgSMKo GxFIqVlfekSs97yBv7iyOuRq+pjhJeF0sLJDxEZOPIu2L5xs2fdK/adV2g== X-Google-Smtp-Source: AGHT+IGOhZSEsmwV9GRJlHXUV9OAV74M64pUjHo1tul8429SCvd9zI3+o9PYpiR4EhluxiGV+xMunw== X-Received: by 2002:a05:6000:1864:b0:381:cde6:4ced with SMTP id ffacd0b85a97d-38225acd3b8mr6304061f8f.45.1731828315197; Sat, 16 Nov 2024 23:25:15 -0800 (PST) Received: from pro2 (pd9e36919.dip0.t-ipconnect.de. [217.227.105.25]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-382398aa925sm3086964f8f.50.2024.11.16.23.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Nov 2024 23:25:14 -0800 (PST) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: (Konstantin Kharlamov's message of "Sat, 16 Nov 2024 20:45:47 +0300") References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> Date: Sun, 17 Nov 2024 08:25:12 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) 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: -1.7 (-) Konstantin Kharlamov writes: > Sure, I just reproduced it after removing all `.elc` files in the repo, > here how: > > 1. `git checkout f2f13fa630b` (a commit from April) > 2. `make -j$(nproc)` to compile. Note: you don't need to wait for build > to finish, I just waited for all files under `lisp/emacs-lisp` > directory to finish compilation, and then ^C'ed it. > 3. `git checkout 29098a291f5` (a November commit). > 4. `make -j$(nproc)` This would always work if lisp/Makefile would rm the .elc files from COMPILE_FIRST, right? I suspect this isn't done to speed up the build in the usual case, and because it's a bit difficult to automatically determine if it has to done or not. Does a "make clean" after the checkout in (3) make it work? From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Alan Mackenzie , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173185691028640 (code B ref 74382); Sun, 17 Nov 2024 15:22:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:21:50 +0000 Received: from localhost ([127.0.0.1]:58081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCh5x-0007Rs-KD for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:21:49 -0500 Received: from forward500d.mail.yandex.net ([178.154.239.208]:39786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCh5t-0007RY-VL for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:21:48 -0500 Received: from mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:2322:0:640:6062:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id 8556860D07; Sun, 17 Nov 2024 18:21:38 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id bLRscLTOoa60-2TLdwnYO; Sun, 17 Nov 2024 18:21:38 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731856898; bh=djoHjKCD4J7TcJJ2IFeu4ZDiHSJcEYmEUOxfVZkUjrE=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=PzMu2dwmvgMMGqZOcH6z54DWd3xlXPJBDkwvG8Wp+p2vuAw7Dn4l40c5g43z7HhJX fKv3ibwKNw2xG/LH0DWlkcnqNufaICAQQxSZLNEbYlz81baKZySo/gTAZUClWUuK/M bcMgy+N+geXd7eE/tqSBlp9+6NcYPdY+4Crwe+HE= Authentication-Results: mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 18:21:36 +0300 In-Reply-To: References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Sun, 2024-11-17 at 08:25 +0100, Gerd M=C3=B6llmann wrote: > Konstantin Kharlamov writes: >=20 > > Sure, I just reproduced it after removing all `.elc` files in the > > repo, > > here how: > >=20 > > 1. `git checkout f2f13fa630b` (a commit from April) > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait for > > build > > to finish, I just waited for all files under `lisp/emacs-lisp` > > directory to finish compilation, and then ^C'ed it. > > 3. `git checkout 29098a291f5` (a November commit). > > 4. `make -j$(nproc)` >=20 > This would always work if lisp/Makefile would rm the .elc files from > COMPILE_FIRST, right? I suspect this isn't done to speed up the build > in > the usual case, and because it's a bit difficult to automatically > determine if it has to done or not. >=20 > Does a "make clean" after the checkout in (3) make it work? I don't think so, because `make clean` for some reason doesn't remove `.elc` artifacts. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173185751030466 (code B ref 74382); Sun, 17 Nov 2024 15:32:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:31:50 +0000 Received: from localhost ([127.0.0.1]:58113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChFd-0007vH-3s for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:31:50 -0500 Received: from forward500d.mail.yandex.net ([178.154.239.208]:43894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChFa-0007uv-PJ for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:31:48 -0500 Received: from mail-nwsmtp-smtp-production-main-39.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:96c7:0:640:6549:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id 64DB360E0A; Sun, 17 Nov 2024 18:31:40 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id cVRntXTOciE0-jvxhiRg5; Sun, 17 Nov 2024 18:31:39 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731857499; bh=JVt6c2cc09zEKM95smJW96wcO5n92H8NXGM4YXb5834=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=o0Eon7QrOosZZkrIV+Y8TcKb5WblaJOaqNuRss1b8YHpiYuFAVE3FMIe4s0hQzZSq 3fqWD4MTiLXmPIo1qLnK/pxgNYrrYuARV/ro4Cw2xlH++VwI7aSpZE+/OVN26eztnB cxP96PJIxgVq+slS8dAZem1Sds1I3DBTK4atpGok= Authentication-Results: mail-nwsmtp-smtp-production-main-39.klg.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <16787fc6f6933aa596427f420319e87d86dac9b0.camel@yandex.ru> From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 18:31:38 +0300 In-Reply-To: <86jzd2we9h.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86o72ff2h0.fsf@gnu.org> <2b134414542a4af7b87435099570fd88c7d25aa6.camel@yandex.ru> <86y11jvthj.fsf@gnu.org> <46a8bf630b89755bd6edc1521390352ecc176881.camel@yandex.ru> <86jzd2we9h.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Sun, 2024-11-17 at 08:44 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: acm@muc.de, 74382@debbugs.gnu.org > > Date: Sun, 17 Nov 2024 01:54:48 +0300 > >=20 > > > It's impractical, because we have many files with macros.=C2=A0 > > > Tracking > > > all of those dependencies would mean that changes in any file > > > will > > > trigger unnecessary recompilation of many other files.=C2=A0 If you > > > don't > > > mind spending that time waiting for the build, just "make > > > bootstrap" > > > every time you update from Git, and you will have that. > >=20 > > Unless I'm missing something, the problem seems to be with one > > exact > > file, macroexpand.elc, and not with others. >=20 > No, that's not true.=C2=A0 I had similar problems with basically all the > files in COMPILE_FIRST. >=20 > More importantly, what you seem to be missing is that we deliberately > play with the time stamps of the *.elc files in COMPILE_FIRST (search > for "UTC" in the Makefile), so we must not use load-prefer-newer in > this case.=C2=A0 That is the reason why it's removed from > BYTE_COMPILE_FLAGS. >=20 > > So the algorithm is simple: if `macroexpand.el` was modified, > > remove > > its elc file. You don't need to track any dependencies. >=20 > How will load-prefer-newer help if this is what you do?=C2=A0 That's the > trigger for this bug report, no? >=20 > In any case, this is not the reason why load-prefer-newer is removed > while we COMPILE_FIRST; see above. Alright, for more efficient discussion I think I need to dig into how this all work in different situations and measure performance, to come up with some suggestions, but I'm afraid ATM I just don't have the spare time, so maybe let's close the discussion for now=E2=80=A6 I just see that COMPILE_FIRST files should never be used while being stale, but for performance reasons they are used stale. I don't think this is the case where the correctness can be traded off for performance, but it's just my opinion. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173185784631449 (code B ref 74382); Sun, 17 Nov 2024 15:38:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:37:26 +0000 Received: from localhost ([127.0.0.1]:58126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChL4-0008BB-44 for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:37:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChL2-0008At-5r for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:37:25 -0500 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 1tChKv-0004BV-KK; Sun, 17 Nov 2024 10:37:17 -0500 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=SskHWetPHrdR74NmXCSmz+b+qq1DFO7M6taziNGd9MQ=; b=j/7bLUyfWkfG5MtDG9K1 k0E+rW8LbWaTZKbM8fUtoKCWI+LqeApgnsjm/wrqHHQqQC4FcISAl40zrtNnuWwSkaXD1K2dyqgp4 4C8fFa/FjfFGCs2FgxOWvhCPfL+G2dqH3WvtudKYT+ZtFAiy5BAmFz0eUEZiL3r74GTfHRiHhzzpn zYdMlY5AieiLmfoXtx3F0VrgchJ9x3Ij3vkE1x8jqmqH8pchqZineTRWsf7dkmkQh4tuKjQV23IKI bQGoZM1blC4LIWvW/J8+RayfWoZnX0PUXZwF0APPe1g2dcKXA8SQTlgw+Z2ALb2NJoPs5qh+eSGsC XCYlxv+0C7taaw==; Date: Sun, 17 Nov 2024 17:37:15 +0200 Message-Id: <861pz9x45w.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 17 Nov 2024 18:21:36 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> 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 (---) > Cc: Alan Mackenzie , 74382@debbugs.gnu.org > From: Konstantin Kharlamov > Date: Sun, 17 Nov 2024 18:21:36 +0300 > > On Sun, 2024-11-17 at 08:25 +0100, Gerd Möllmann wrote: > > Konstantin Kharlamov writes: > > > > > Sure, I just reproduced it after removing all `.elc` files in the > > > repo, > > > here how: > > > > > > 1. `git checkout f2f13fa630b` (a commit from April) > > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait for > > > build > > > to finish, I just waited for all files under `lisp/emacs-lisp` > > > directory to finish compilation, and then ^C'ed it. > > > 3. `git checkout 29098a291f5` (a November commit). > > > 4. `make -j$(nproc)` > > > > This would always work if lisp/Makefile would rm the .elc files from > > COMPILE_FIRST, right? I suspect this isn't done to speed up the build > > in > > the usual case, and because it's a bit difficult to automatically > > determine if it has to done or not. > > > > Does a "make clean" after the checkout in (3) make it work? > > I don't think so, because `make clean` for some reason doesn't remove > `.elc` artifacts. And it shouldn't, because *.elc files are part of a release tarball. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173185820832529 (code B ref 74382); Sun, 17 Nov 2024 15:44:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:43:28 +0000 Received: from localhost ([127.0.0.1]:58150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChQu-0008Sa-Fq for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:43:28 -0500 Received: from forward500b.mail.yandex.net ([178.154.239.144]:36084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChQr-0008S9-Oq for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:43:26 -0500 Received: from mail-nwsmtp-smtp-production-main-57.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-57.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:261a:0:640:f38:0]) by forward500b.mail.yandex.net (Yandex) with ESMTPS id 1654360CC6; Sun, 17 Nov 2024 18:43:19 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-57.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id HhR6W9DOpKo0-gNvfYmCk; Sun, 17 Nov 2024 18:43:18 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731858198; bh=k8Xq2/YnN3vO4yijWrRpTHmZNWih4f4aLkevckcpjp0=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=U2fAuRWT+iHcG1e3lBuek1OXH7E8qYNHM3ofu182UNpRr8EyH7PN6viQegnzb3jiv NNsMoe0MXsfO6ro5ZfyLiEW8esf0TBM5UwIE2NrWv9UnTafgw9+hukWVAaNfvfDdJ+ IXvBOZmxn20Uk2Y5IdnuG0Ko5LzOBHa6gSXO7q+8= Authentication-Results: mail-nwsmtp-smtp-production-main-57.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 18:43:17 +0300 In-Reply-To: <861pz9x45w.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Sun, 2024-11-17 at 17:37 +0200, Eli Zaretskii wrote: > > Cc: Alan Mackenzie , 74382@debbugs.gnu.org > > From: Konstantin Kharlamov > > Date: Sun, 17 Nov 2024 18:21:36 +0300 > >=20 > > On Sun, 2024-11-17 at 08:25 +0100, Gerd M=C3=B6llmann wrote: > > > Konstantin Kharlamov writes: > > >=20 > > > > Sure, I just reproduced it after removing all `.elc` files in > > > > the > > > > repo, > > > > here how: > > > >=20 > > > > 1. `git checkout f2f13fa630b` (a commit from April) > > > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait > > > > for > > > > build > > > > to finish, I just waited for all files under `lisp/emacs-lisp` > > > > directory to finish compilation, and then ^C'ed it. > > > > 3. `git checkout 29098a291f5` (a November commit). > > > > 4. `make -j$(nproc)` > > >=20 > > > This would always work if lisp/Makefile would rm the .elc files > > > from > > > COMPILE_FIRST, right? I suspect this isn't done to speed up the > > > build > > > in > > > the usual case, and because it's a bit difficult to automatically > > > determine if it has to done or not. > > >=20 > > > Does a "make clean" after the checkout in (3) make it work? > >=20 > > I don't think so, because `make clean` for some reason doesn't > > remove > > `.elc` artifacts. >=20 > And it shouldn't, because *.elc files are part of a release tarball. But if someone decided to build from a release tarball, sure they can produce .elc files as well, can't they? From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: Alan Mackenzie , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173185825132630 (code B ref 74382); Sun, 17 Nov 2024 15:45:01 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:44:11 +0000 Received: from localhost ([127.0.0.1]:58154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChRa-0008UD-Tx for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:44:11 -0500 Received: from mail-wm1-f46.google.com ([209.85.128.46]:57807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChRZ-0008U0-37 for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:44:09 -0500 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4315839a7c9so30696515e9.3 for <74382@debbugs.gnu.org>; Sun, 17 Nov 2024 07:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731858183; x=1732462983; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PRjj3Q8JQQoo8+HxHLpHIFPleTQlfKLh9EYYfqANL/4=; b=cWJWKmFtOZpHDSaEP4HfVb7H0gMumDGvLj6sBNinzVpZZcli/ObVMRMDEo0t6vqIfQ /ysFBX5DA8em5cGAP9kFyE3z5OxR8R1GPZbr9zOB4Cg+qEiQu49fqjw/z/TD8UG2Fkey HBQ/ZZ1cRDitk5RWTsPcXIWzlvc5UsOwYYlm+YMX4elUzIfg/Xi0mah8kK5UqeB1TvW6 cIAyZIt8eE1tYpuTINqo91do3pMXs3gL0wh3J1W/Pmr1ttR2J4CsZJhws6LnJQDgIspu xeidS2IsH8a3GehCJ5I1HMWv8j0OZFxAENfMrkGTLGKBx03yi5ElcCbTK5DYUhPNmKRc q02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731858183; x=1732462983; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PRjj3Q8JQQoo8+HxHLpHIFPleTQlfKLh9EYYfqANL/4=; b=WJNfZuDQYx21ARTmXPNBweVkyUPX4/GWrMlP8QPn09gVZfXQDljgEp18wqNnRzwLHx mRMXRHpdeewKtFkm4kYQ7CuhcY1SQzuO0tbGnoPTEjyJbLm0O5TjwDiN/SZMUU49WBsH mHciqlrW9b/8knaxxW8z8lrecoQf0u8reXh5sFf/28qZFWpY4T9OOm75yko1tqlKLCT/ T2eItIgt57aNKbbMnidvVab1SO4gBfbqM+7SIfaycTxQunYZwm1aPsnEgsDljdH6qtKo /AR31+DXsXpKeN/AYXkmQ+2qPbkihl6HdhrP2xgyfyqbQFvOB8DUvCL8OP0UZAPFY/Eg hKzQ== X-Forwarded-Encrypted: i=1; AJvYcCX++2H+NufHF4nE7OAFEP7xgyU/zkr/3kzbk9pSGiWcxKWGuNIYCJQ9UKHFxPiKlXZXUtPPfw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YytfQWdVk4l+SXDrg15nhoI8UYiHCOqu8hK5M4hvwhngb4/SBEb IOr448EKEGOzvh2IrWRYqm0R4tErRMkKx+PFEst/w5xWxuiqI4HVQtplXQ== X-Google-Smtp-Source: AGHT+IHiy+Jp0ZfdbMjnu1unETgb1meMx5XfffSkpbTiG9qNyXLd4I8naLWouxAr73Vs3vTiReISbw== X-Received: by 2002:a05:6000:184d:b0:382:46d2:52ae with SMTP id ffacd0b85a97d-38246d253f7mr604760f8f.21.1731858182673; Sun, 17 Nov 2024 07:43:02 -0800 (PST) Received: from pro2 (pd9e36919.dip0.t-ipconnect.de. [217.227.105.25]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38223272da0sm8309298f8f.32.2024.11.17.07.43.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Nov 2024 07:43:02 -0800 (PST) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> (Konstantin Kharlamov's message of "Sun, 17 Nov 2024 18:21:36 +0300") References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> Date: Sun, 17 Nov 2024 16:43:01 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) 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: -1.7 (-) Konstantin Kharlamov writes: > On Sun, 2024-11-17 at 08:25 +0100, Gerd M=C3=B6llmann wrote: >> Konstantin Kharlamov writes: >>=20 >> > Sure, I just reproduced it after removing all `.elc` files in the >> > repo, >> > here how: >> >=20 >> > 1. `git checkout f2f13fa630b` (a commit from April) >> > 2. `make -j$(nproc)` to compile. Note: you don't need to wait for >> > build >> > to finish, I just waited for all files under `lisp/emacs-lisp` >> > directory to finish compilation, and then ^C'ed it. >> > 3. `git checkout 29098a291f5` (a November commit). >> > 4. `make -j$(nproc)` >>=20 >> This would always work if lisp/Makefile would rm the .elc files from >> COMPILE_FIRST, right? I suspect this isn't done to speed up the build >> in >> the usual case, and because it's a bit difficult to automatically >> determine if it has to done or not. >>=20 >> Does a "make clean" after the checkout in (3) make it work? > > I don't think so, because `make clean` for some reason doesn't remove > `.elc` artifacts. Ah, right, it is bootstrap-clean that removes the .elc files. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 15:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17318588041948 (code B ref 74382); Sun, 17 Nov 2024 15:54:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 15:53:24 +0000 Received: from localhost ([127.0.0.1]:58175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChaV-0000VL-HU for submit@debbugs.gnu.org; Sun, 17 Nov 2024 10:53:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChaR-0000V3-RG for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 10:53:21 -0500 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 1tChaL-0006kj-Ek; Sun, 17 Nov 2024 10:53:13 -0500 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=z9wDUh2vlrwhOAek/Qc0+TkMEp022ss5JHBVW/U5JRs=; b=VCDklm0OEo81tNpjyUOk yNUSZcM7ADh9xx9rJFLjt4beHJa3PjVGGF270z0jGbvp8vJDXiSdf7Ify7wGHOAb8kG5QXSmsRaKT iPBDsn9y71dHd+sLx7rveHZdC82pMNlgvtz2oaQaZeBR3THobTEunNoc+hrlLix5hp1A4OziDocOY FmgFLZG4WAwwPW7nqJd17As5UBnSMeJinBSw8JqMFTmGcJmmb8cjUqqFGE5rtjq274JiZeLXvi9Re dcsjkmTuA/X3TEbjQIlS5vxNiBKY/m2i2yRqH9gDkRNa8ygxUJJrBe0b93orH8SdZRsUuKJOej8CJ RZoxcz+wKcabZw==; Date: Sun, 17 Nov 2024 17:53:10 +0200 Message-Id: <86zflxvoux.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Konstantin Kharlamov on Sun, 17 Nov 2024 18:43:17 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.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: Konstantin Kharlamov > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > Date: Sun, 17 Nov 2024 18:43:17 +0300 > > On Sun, 2024-11-17 at 17:37 +0200, Eli Zaretskii wrote: > > > Cc: Alan Mackenzie , 74382@debbugs.gnu.org > > > From: Konstantin Kharlamov > > > Date: Sun, 17 Nov 2024 18:21:36 +0300 > > > > > > On Sun, 2024-11-17 at 08:25 +0100, Gerd Möllmann wrote: > > > > Konstantin Kharlamov writes: > > > > > > > > > Sure, I just reproduced it after removing all `.elc` files in > > > > > the > > > > > repo, > > > > > here how: > > > > > > > > > > 1. `git checkout f2f13fa630b` (a commit from April) > > > > > 2. `make -j$(nproc)` to compile. Note: you don't need to wait > > > > > for > > > > > build > > > > > to finish, I just waited for all files under `lisp/emacs-lisp` > > > > > directory to finish compilation, and then ^C'ed it. > > > > > 3. `git checkout 29098a291f5` (a November commit). > > > > > 4. `make -j$(nproc)` > > > > > > > > This would always work if lisp/Makefile would rm the .elc files > > > > from > > > > COMPILE_FIRST, right? I suspect this isn't done to speed up the > > > > build > > > > in > > > > the usual case, and because it's a bit difficult to automatically > > > > determine if it has to done or not. > > > > > > > > Does a "make clean" after the checkout in (3) make it work? > > > > > > I don't think so, because `make clean` for some reason doesn't > > > remove > > > `.elc` artifacts. > > > > And it shouldn't, because *.elc files are part of a release tarball. > > But if someone decided to build from a release tarball, sure they can > produce .elc files as well, can't they? No, Emacs release tarballs come with *.elc files, and users shouldn't recompile them. For starters, it makes the build significantly longer, besides being unnecessary. Recompiling *.elc files is only needed if the corresponding *.el files are modified, something that doesn't normally happen when you build a release tarball. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 16:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17318594933907 (code B ref 74382); Sun, 17 Nov 2024 16:05:01 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 16:04:53 +0000 Received: from localhost ([127.0.0.1]:58188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChlc-00010x-VC for submit@debbugs.gnu.org; Sun, 17 Nov 2024 11:04:53 -0500 Received: from forward502b.mail.yandex.net ([178.154.239.146]:35306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tChla-00010c-38 for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 11:04:52 -0500 Received: from mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:1115:0:640:1385:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 582E861038; Sun, 17 Nov 2024 19:04:43 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id g4SmflVOn8c0-k28aLhfk; Sun, 17 Nov 2024 19:04:42 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731859482; bh=WQvowaJiSB76Co+Uw7ot8k+5G2npdtMuaAxS0tmSh58=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=p6m3a6y9mEUP+C/aXi1a68qPBen4cdlU5PTeIXRqz9Ve5nuA4tUtvOvmVYO5wusAc vWLmfBuocXzN361pYpejCf8pWHo5g2zWajHUA5IheD1Ss3w6+uwxeOhko5Chi93G+Z 2JK3ze7vpyZkzLQvl12UdYmM4t3jBwNzQymr0Ezs= Authentication-Results: mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 19:04:42 +0300 In-Reply-To: <86zflxvoux.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 X-Spam-Score: 1.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: -1.0 (-) On Sun, 2024-11-17 at 17:53 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > > Date: Sun, 17 Nov 2024 18:43:17 +0300 > >=20 > > On Sun, 2024-11-17 at 17:37 +0200, Eli Zaretskii wrote: > > > > Cc: Alan Mackenzie , 74382@debbugs.gnu.org > > > > From: Konstantin Kharlamov > > > > Date: Sun, 17 Nov 2024 18:21:36 +0300 > > > >=20 > > > > On Sun, 2024-11-17 at 08:25 +0100, Gerd M=C3=B6llmann wrote: > > > > > Konstantin Kharlamov writes: > > > > >=20 > > > > > > Sure, I just reproduced it after removing all `.elc` files > > > > > > in > > > > > > the > > > > > > repo, > > > > > > here how: > > > > > >=20 > > > > > > 1. `git checkout f2f13fa630b` (a commit from April) > > > > > > 2. `make -j$(nproc)` to compile. Note: you don't need to > > > > > > wait > > > > > > for > > > > > > build > > > > > > to finish, I just waited for all files under `lisp/emacs- > > > > > > lisp` > > > > > > directory to finish compilation, and then ^C'ed it. > > > > > > 3. `git checkout 29098a291f5` (a November commit). > > > > > > 4. `make -j$(nproc)` > > > > >=20 > > > > > This would always work if lisp/Makefile would rm the .elc > > > > > files > > > > > from > > > > > COMPILE_FIRST, right? I suspect this isn't done to speed up > > > > > the > > > > > build > > > > > in > > > > > the usual case, and because it's a bit difficult to > > > > > automatically > > > > > determine if it has to done or not. > > > > >=20 > > > > > Does a "make clean" after the checkout in (3) make it work? > > > >=20 > > > > I don't think so, because `make clean` for some reason doesn't > > > > remove > > > > `.elc` artifacts. > > >=20 > > > And it shouldn't, because *.elc files are part of a release > > > tarball. > >=20 > > But if someone decided to build from a release tarball, sure they > > can > > produce .elc files as well, can't they? >=20 > No, Emacs release tarballs come with *.elc files, and users shouldn't > recompile them.=C2=A0 For starters, it makes the build significantly > longer, besides being unnecessary. >=20 > Recompiling *.elc files is only needed if the corresponding *.el > files > are modified, something that doesn't normally happen when you build a > release tarball. Okay. So, how about a compromise here: provide release tarball with modified Makefiles which upon calling `make clean` would not remove `.elc` files =E2=80=94 but let `make clean` inside git-repository remove el= c files? Users expect `make clean` to remove non-config-related bulid artifacts. Which includes `.elc` files. I can't count how many times I was forgetting about this peculiarity of Emacs build system, and after finding out that even `make clean` doesn't help with build errors (due to COMPILE_FIRST files stuff), I had to nuke everything with `git clean -fdx`. Even Gerd in this discussion forgot about this peculiarity =E2=80=94= and Gerd unlike me is a regular Emacs developer. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 16:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17318610068923 (code B ref 74382); Sun, 17 Nov 2024 16:31:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 16:30:06 +0000 Received: from localhost ([127.0.0.1]:58247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCiA1-0002Ji-5V for submit@debbugs.gnu.org; Sun, 17 Nov 2024 11:30:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCi9y-0002HP-Vk for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 11:30:03 -0500 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 1tCi9s-0005ET-MZ; Sun, 17 Nov 2024 11:29:56 -0500 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=/qzF1fk1QcsmQcsMfdgu8DltTZDY6hE+O+u3zRJHF2o=; b=DJ4F/dJdJJZq2OGPFU91 PFQQ7f3z02DjLYWcnG0YF0u5eJItvOvUQjAuuwRcN3achU2f/bkR6LCDchIAxhGiVyG5iNl806Ouy YzyFT8L72D5q6Lp+yyq+JMNE6UZQPJQbSVtLmJffNzh2y6MgCTVyPYPcYJ35dR15EEDvOrt8sgDWH vRlk6i6YbLcvSNhH/8IKIH6GXo+zPRvFBmJEHPzTXn6QSPAkYmR28lLdbRICYSTy4U3Bt/WnEccLx 5a4ccA3Q8E4G8s6TAynXOhODdni3oWAQMZedm6pN/K03l0KO0xQQS8wvbVDUvJFLao8MsEp0GAPCs f9Du9Bw5pxI+Gw==; Date: Sun, 17 Nov 2024 18:29:52 +0200 Message-Id: <86y11hvn5r.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Konstantin Kharlamov on Sun, 17 Nov 2024 19:04:42 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.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: Konstantin Kharlamov > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > Date: Sun, 17 Nov 2024 19:04:42 +0300 > > On Sun, 2024-11-17 at 17:53 +0200, Eli Zaretskii wrote: > > No, Emacs release tarballs come with *.elc files, and users shouldn't > > recompile them.  For starters, it makes the build significantly > > longer, besides being unnecessary. > > > > Recompiling *.elc files is only needed if the corresponding *.el > > files > > are modified, something that doesn't normally happen when you build a > > release tarball. > > Okay. So, how about a compromise here: provide release tarball with > modified Makefiles which upon calling `make clean` would not remove > `.elc` files — but let `make clean` inside git-repository remove elc > files? We already have a special target for that: maintainer-clean. There's no need to make such confusing differences between what "make clean" does in a tarball and in Git. That's a standard GNU target, so it should do what the GNU Coding Standards say, and do it consistently. Removing all the *.elc files (and a few *.el files that are generated by the build from Git) makes the build much longer, so doing so should be harder and rarer, not easier and more frequent. > Users expect `make clean` to remove non-config-related bulid artifacts. > Which includes `.elc` files. I can't count how many times I was > forgetting about this peculiarity of Emacs build system, and after > finding out that even `make clean` doesn't help with build errors (due > to COMPILE_FIRST files stuff), I had to nuke everything with `git clean > -fdx`. Even Gerd in this discussion forgot about this peculiarity — and > Gerd unlike me is a regular Emacs developer. You will have to get used to this curiosity of the Emacs build system, sorry. The main audience of the build stuff in Git is Emacs developers, so everyone else have to adapt. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173186202512207 (code B ref 74382); Sun, 17 Nov 2024 16:48:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 16:47:05 +0000 Received: from localhost ([127.0.0.1]:58308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCiQT-0003Ao-5p for submit@debbugs.gnu.org; Sun, 17 Nov 2024 11:47:05 -0500 Received: from forward500a.mail.yandex.net ([178.154.239.80]:42062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCiQR-0003AF-FM for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 11:47:04 -0500 Received: from mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net [IPv6:2a02:6b8:c15:339a:0:640:a002:0]) by forward500a.mail.yandex.net (Yandex) with ESMTPS id 6F26060EE1; Sun, 17 Nov 2024 19:46:27 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id PkSIoYXOc0U0-u0tuJadN; Sun, 17 Nov 2024 19:46:26 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731861987; bh=mDuOW347I2gZVktve1PFcc7rB2nk+WTcn5k1iNqg1V4=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=gaTe8UNCUsXA+x/HgY1aW9i+U0NniYqNShsBlNL6g96NL31PmcTWXaAwE6m+FoJjP GYlV9+yWmqIzglZl1+nXxxYMEQ7ztEdDXRPm5e3dAethx2zQAuAZoTkowzw013WqU+ YkR6/mAhtJh0CBbUjfnEz0sHmga2qzgp6LIwqpGw= Authentication-Results: mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 19:46:25 +0300 In-Reply-To: <86y11hvn5r.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <86y11hvn5r.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 X-Spam-Score: 1.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: -1.0 (-) On Sun, 2024-11-17 at 18:29 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > > Date: Sun, 17 Nov 2024 19:04:42 +0300 > >=20 > > On Sun, 2024-11-17 at 17:53 +0200, Eli Zaretskii wrote: > > > No, Emacs release tarballs come with *.elc files, and users > > > shouldn't > > > recompile them.=C2=A0 For starters, it makes the build significantly > > > longer, besides being unnecessary. > > >=20 > > > Recompiling *.elc files is only needed if the corresponding *.el > > > files > > > are modified, something that doesn't normally happen when you > > > build a > > > release tarball. > >=20 > > Okay. So, how about a compromise here: provide release tarball with > > modified Makefiles which upon calling `make clean` would not remove > > `.elc` files =E2=80=94 but let `make clean` inside git-repository remov= e > > elc > > files? >=20 > We already have a special target for that: maintainer-clean.=C2=A0 There'= s > no need to make such confusing differences between what "make clean" > does in a tarball and in Git.=C2=A0 That's a standard GNU target, so it > should do what the GNU Coding Standards say, and do it consistently. GNU Coding Standard section for `make clean` says, quoting: > Delete all files [=E2=80=A6] that are normally created by building the program. However, don=E2=80=99t delete the files that record the configurat= ion. Also preserve files that could be made by building, but normally aren=E2=80= =99t because the distribution comes with them. The "git distribution" doesn't come with .elc files, hence .elc files should be removed by `make clean` if run in the git repository. That's what the standard says. > Removing all the *.elc files (and a few *.el files that are generated > by the build from Git) makes the build much longer, so doing so > should > be harder and rarer, not easier and more frequent. You are optimizing for the wrong people. The auditory for release tarballs are package maintainers, and they couldn't care less if `make clean` removes all artifacts or not, because: 1. Nowadays the majority don't package on their personal machines anyway and use CI, and 2. they don't typically execute `make clean`. This "don't clean elc files during `make clean`" hurts Emacs devs and contributors, while gaining nothing in return. > > Users expect `make clean` to remove non-config-related bulid > > artifacts. > > Which includes `.elc` files. I can't count how many times I was > > forgetting about this peculiarity of Emacs build system, and after > > finding out that even `make clean` doesn't help with build errors > > (due > > to COMPILE_FIRST files stuff), I had to nuke everything with `git > > clean > > -fdx`. Even Gerd in this discussion forgot about this peculiarity =E2= =80=94 > > and > > Gerd unlike me is a regular Emacs developer. >=20 > You will have to get used to this curiosity of the Emacs build > system, > sorry.=C2=A0 The main audience of the build stuff in Git is Emacs > developers, so everyone else have to adapt. I don't think Emacs developers are using release tarballs, so this "curiosity" isn't helping them. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 17:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173186340716435 (code B ref 74382); Sun, 17 Nov 2024 17:11:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 17:10:07 +0000 Received: from localhost ([127.0.0.1]:58391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCimk-0004Gv-8x for submit@debbugs.gnu.org; Sun, 17 Nov 2024 12:10:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCimh-0004DR-Jo for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 12:10:04 -0500 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 1tCimb-0003oZ-Mf; Sun, 17 Nov 2024 12:09:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pp+mNkXj3QbmR2ZE15QDgTk70BWhQ6p6s4R0YycYlB8=; b=PdoISK20E/zZtdgY8/2z Wum2HB5u6JKmQJ4+fxR1JTTGxAoeWeGEWM0BiCVw9/DBQHWRYDpDHi7j/AccljGjbDMHp83cMdDI/ fYlM4NUA+LtdswSm7derf1Fptm/XIchMC8BlUxaHKIUgR70UMqhglh1VBHuv1fizANUL19qZcAeus uEUEATQVWMbh2hpbAGPq4at5iFYFqIjwywbYSsSe9gK3/JY6PlQx8ceoi/Y4b6Z/M5c7haIwJnDM0 J6T0G1finIvS8zVB97pyAGdXadME2uSoRo0rCpRmVUCfdp62q6qpUti9w/CZ2NoO3b7+YBRMxNmpl Mpf5+5fIOH2NWA==; Date: Sun, 17 Nov 2024 19:09:45 +0200 Message-Id: <86serpvlba.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Konstantin Kharlamov on Sun, 17 Nov 2024 19:46:25 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <86y11hvn5r.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: Konstantin Kharlamov > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > Date: Sun, 17 Nov 2024 19:46:25 +0300 > > On Sun, 2024-11-17 at 18:29 +0200, Eli Zaretskii wrote: > > We already have a special target for that: maintainer-clean.  There's > > no need to make such confusing differences between what "make clean" > > does in a tarball and in Git.  That's a standard GNU target, so it > > should do what the GNU Coding Standards say, and do it consistently. > > GNU Coding Standard section for `make clean` says, quoting: > > > Delete all files […] that are normally created by building the > program. However, don’t delete the files that record the configuration. > Also preserve files that could be made by building, but normally aren’t > because the distribution comes with them. > > The "git distribution" doesn't come with .elc files, hence .elc files > should be removed by `make clean` if run in the git repository. That's > what the standard says. There's no "Git distribution", so this doesn't apply. Once again, it is more important to me that "make clean" does the same in every case than anything else. > This "don't clean elc files during `make clean`" hurts Emacs devs and > contributors, while gaining nothing in return. I disagree. > > You will have to get used to this curiosity of the Emacs build > > system, > > sorry.  The main audience of the build stuff in Git is Emacs > > developers, so everyone else have to adapt. > > I don't think Emacs developers are using release tarballs, so this > "curiosity" isn't helping them. The curiosity is for those who build from tarballs, whoever they are. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Nov 2024 17:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173186425918819 (code B ref 74382); Sun, 17 Nov 2024 17:25:02 +0000 Received: (at 74382) by debbugs.gnu.org; 17 Nov 2024 17:24:19 +0000 Received: from localhost ([127.0.0.1]:58427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCj0V-0004tT-E6 for submit@debbugs.gnu.org; Sun, 17 Nov 2024 12:24:19 -0500 Received: from forward501b.mail.yandex.net ([178.154.239.145]:54310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCj0S-0004tC-WB for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 12:24:18 -0500 Received: from mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:18aa:0:640:5723:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id 6D4C660EEF; Sun, 17 Nov 2024 20:24:10 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 8OTjiJWOhSw0-G4RECJ8w; Sun, 17 Nov 2024 20:24:09 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731864249; bh=EfFo4fe3NuAFcvNm+WQLCHsw1asL8aPFCWP1xJSNY+s=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=xBcbgy6jyDI02HEDhw/4oSXqYeIS0odi1MHb6RsQCp9oPsEwo1dyKrbr4NjwRVNTA QLOWdPdbL/gwkvCjnv1eH4D3qN0zsuvB9SsbMt+XBave+GWoID+23XZ/o/rQ6DMNc8 23OF9og0C/CjZwOsPbg/aBC/HxPN0BVkDrSG5I4o= Authentication-Results: mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <7e381be45c124103de80aa70ce21726706788988.camel@yandex.ru> From: Konstantin Kharlamov Date: Sun, 17 Nov 2024 20:24:08 +0300 In-Reply-To: <86serpvlba.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <86y11hvn5r.fsf@gnu.org> <86serpvlba.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 X-Spam-Score: 1.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: -1.0 (-) On Sun, 2024-11-17 at 19:09 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: gerd.moellmann@gmail.com, acm@muc.de, 74382@debbugs.gnu.org > > Date: Sun, 17 Nov 2024 19:46:25 +0300 > >=20 > > On Sun, 2024-11-17 at 18:29 +0200, Eli Zaretskii wrote: > > > We already have a special target for that: maintainer-clean.=C2=A0 > > > There's > > > no need to make such confusing differences between what "make > > > clean" > > > does in a tarball and in Git.=C2=A0 That's a standard GNU target, so > > > it > > > should do what the GNU Coding Standards say, and do it > > > consistently. > >=20 > > GNU Coding Standard section for `make clean` says, quoting: > >=20 > > > Delete all files [=E2=80=A6] that are normally created by building th= e > > program. However, don=E2=80=99t delete the files that record the > > configuration. > > Also preserve files that could be made by building, but normally > > aren=E2=80=99t > > because the distribution comes with them. > >=20 > > The "git distribution" doesn't come with .elc files, hence .elc > > files > > should be removed by `make clean` if run in the git repository. > > That's > > what the standard says. >=20 > There's no "Git distribution", so this doesn't apply. The Cambridge Dictionary defines word "distribution" as=C2=B9: > the process of giving things out to several people, or spreading or supplying something Git repo provides people with Emacs sources, so that does apply. > Once again, it is more important to me that "make clean" does the > same > in every case than anything else. >=20 > > This "don't clean elc files during `make clean`" hurts Emacs devs > > and > > contributors, while gaining nothing in return. >=20 > I disagree. Well, since we ruled out the distro packagers as the auditory for the `make clean`, who else do you see would benefit from it? > > > You will have to get used to this curiosity of the Emacs build > > > system, > > > sorry.=C2=A0 The main audience of the build stuff in Git is Emacs > > > developers, so everyone else have to adapt. > >=20 > > I don't think Emacs developers are using release tarballs, so this > > "curiosity" isn't helping them. >=20 > The curiosity is for those who build from tarballs, whoever they are. Here's the thing, the `foo clean` target in any build system in 95% of cases in my experience is only used to work around the bugs in how the project set up the build system, more specifically when compilation command doesn't rebuild project properly. In Emacs we already know that the bug is only with those COMPILE_FIRST files. A release tarball user is very unlikely to modify exactly those files and exactly in a way to would lead to the problem. Hence the user is very unlikely to use `make clean` whatsoever. And then, even if they do catch the bug, they again *do* want to get rid of the offending files. So overall, I just don't see who would ever want `make clean` not to remove `.elc` files, even among tarball users. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 04:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: acm@muc.de, Eli Zaretskii , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17319028363979 (code B ref 74382); Mon, 18 Nov 2024 04:08:02 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 04:07:16 +0000 Received: from localhost ([127.0.0.1]:59442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCt2i-000127-9U for submit@debbugs.gnu.org; Sun, 17 Nov 2024 23:07:16 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:53336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCt2c-00011r-2I for 74382@debbugs.gnu.org; Sun, 17 Nov 2024 23:07:14 -0500 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4315eeb2601so24132385e9.2 for <74382@debbugs.gnu.org>; Sun, 17 Nov 2024 20:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731902769; x=1732507569; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=arbTlGmr4UO9QIUAeutvXxEKD5UyxNJdzyk6DRmnuZE=; b=I3j1r5GyBByn+UobhgnpNM6R+QY3BNP1Aa5MBX9QVA4YSMiRKPtgS7yg1JT9D8vrmp UYWG9wYOZ3MeQpGl14dUY9YZntszvUXlXVqyTzyOX8FgkFKuOcyHy+qlcdRoaSAOql+p OwBL9JXtNbvw9HLWX1bjV+kWWR9GmSxqS54ebWp8vGOBIUtQTxdscb+z6SL2esw5GGaf mUEq+g+Amkedt3Mb/HFMLMno51XY9YVmytaH6xqUE3OerTr5d8M4qhOTggY4KGZGCgPV vppoEjmJBsM3FlgxMN1HQZzCGw72d+irsRFbZF1FCF70j/ojdkjc0ERXh1b05nOJVHBy ik4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731902769; x=1732507569; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=arbTlGmr4UO9QIUAeutvXxEKD5UyxNJdzyk6DRmnuZE=; b=lwLA5DTArXtCa39LDd3nk/5UUs52xJJvSPxq/LQFvaMj27HbP7rji7rz4DO46mwpZr +FrFVOfw/Tbqyvux8zKLulI5dmKRiQnbV1WY+yq56t1ICGbTYdxrrVKOM9vN2PXLGGJi zyLO8NWze/KIpMDM/JR60AM4LPEFoRN3mlfOKXMO6kCiLdJtOluN5SicAig2JQhieWDX cd6ioTkYtmJM4nyq/jBDM6wGjzjbLg+v4HAKTd4QvY/D1iqUFECJf8cuN9J9uGCxJZbw ZxGN97GzCPdU3u3G9w5z60V6ml+orVZoYLXcHsZ6RuPaO3RJmE6qvz84DWOtxx8eV1tx f0Qg== X-Forwarded-Encrypted: i=1; AJvYcCVDkSy55/d7rKjXHOpk+0mGW8iKUmkuZRIzpGhalFHc5q3A56eGMNz+hLVXghXt3pjgvQz+qQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxkjt+4PQWBwCqssIBR41K9LuXeZZ3wqZlt5hbjug4pS+DS6Z5i wtm/rUbfueY2W/PSgo9PEf9K5ZQ7eLbS/uwBpHqyJv/Wu6fcFfjoBUn7Iw== X-Google-Smtp-Source: AGHT+IFgs7RktQZQHvrQnSPgWKa8ryJx9jrf6lGTrgXIuXO8V7wCHBef4B1pcZ/1MGxjcfi5EkJSHw== X-Received: by 2002:a5d:5f04:0:b0:382:22d5:1d93 with SMTP id ffacd0b85a97d-382255f4022mr11617772f8f.0.1731902768651; Sun, 17 Nov 2024 20:06:08 -0800 (PST) Received: from pro2 (p4fe3a61a.dip0.t-ipconnect.de. [79.227.166.26]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-382371a5646sm6054483f8f.0.2024.11.17.20.06.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Nov 2024 20:06:07 -0800 (PST) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: (Konstantin Kharlamov's message of "Sun, 17 Nov 2024 19:04:42 +0300") References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> Date: Mon, 18 Nov 2024 05:06:05 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) 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: -1.7 (-) Konstantin Kharlamov writes: > Even Gerd in this discussion forgot about this peculiarity =E2=80=94 and > Gerd unlike me is a regular Emacs developer. Even worse, even worse: He wrote that stuff! But I think I'll excuse him because that was 25 years ago, and he took a 20 year break from Emacs, after stepping down, and he's old of course :-). Seriously, maybe knowing a bit of history helps understand the current situation wrt .elc files? One wouldn't believe it nowadays, but they were originally in version control, i.e. RCS, and later CVS. I didn't want that in the public CVS repo we set up for Emacs 21, so I added the ability to bootstrap and removed the .elc files from CVS. COMPILE_FIRST and so on are part of the bootstrapping support. Rewriting the build system to follow some standard (if it existed back then, which I don't remember), was not important to me. There were so many other things to do. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 06:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: acm@muc.de, Eli Zaretskii , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173191078127549 (code B ref 74382); Mon, 18 Nov 2024 06:20:02 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 06:19:41 +0000 Received: from localhost ([127.0.0.1]:59640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCv6q-0007AH-OY for submit@debbugs.gnu.org; Mon, 18 Nov 2024 01:19:41 -0500 Received: from forward501b.mail.yandex.net ([178.154.239.145]:49450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCv6o-00079u-Ds for 74382@debbugs.gnu.org; Mon, 18 Nov 2024 01:19:39 -0500 Received: from mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net [IPv6:2a02:6b8:c1c:320f:0:640:c550:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id E9F1260D97; Mon, 18 Nov 2024 09:19:31 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id UJJIMVcOriE0-2fXO1d0P; Mon, 18 Nov 2024 09:19:31 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731910771; bh=vXGYE8gXIET4k8giNPJZTmsyuXPlLSRLOvmp313SR7k=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=V7cgJiEHRVmqFvw+8GX6qLpwzIJAe1Zjvl08Lvene4dlpZNqTCSFe/9j9+Nc9txUc X6ALMIv7aiT759VOpcyzmRjy9AOO45581DRhNFrx3XOPH+gTDrXdab+DIXqw9VCe6A k9hucvoY6nVM8/XhyYie9yzbFnoGDqiqKiReuDWA= Authentication-Results: mail-nwsmtp-smtp-production-main-19.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <62fa99012d611a7510ec12268cd3710a8c0eb916.camel@yandex.ru> From: Konstantin Kharlamov Date: Mon, 18 Nov 2024 09:19:30 +0300 In-Reply-To: References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Mon, 2024-11-18 at 05:06 +0100, Gerd M=C3=B6llmann wrote: > Konstantin Kharlamov writes: >=20 > > Even Gerd in this discussion forgot about this peculiarity =E2=80=94 an= d > > Gerd unlike me is a regular Emacs developer. >=20 > Even worse, even worse: He wrote that stuff! But I think I'll excuse > him > because that was 25 years ago, and he took a 20 year break from > Emacs, > after stepping down, and he's old of course :-). >=20 > Seriously, maybe knowing a bit of history helps understand the > current > situation wrt .elc files? One wouldn't believe it nowadays, but they > were originally in version control, i.e. RCS, and later CVS. I didn't > want that in the public CVS repo we set up for Emacs 21, so I added > the > ability to bootstrap and removed the .elc files from CVS. > COMPILE_FIRST > and so on are part of the bootstrapping support. >=20 > Rewriting the build system to follow some standard (if it existed > back > then, which I don't remember), was not important to me. There were so > many other things to do. Haha, well, everything gets improved iteratively, so that's okay =F0=9F=98= =8A From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 10:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: acm@muc.de, Eli Zaretskii , 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17319243673989 (code B ref 74382); Mon, 18 Nov 2024 10:07:02 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 10:06:07 +0000 Received: from localhost ([127.0.0.1]:60049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCydy-00012H-Lt for submit@debbugs.gnu.org; Mon, 18 Nov 2024 05:06:07 -0500 Received: from forward500d.mail.yandex.net ([178.154.239.208]:46904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCydu-00011g-Rp for 74382@debbugs.gnu.org; Mon, 18 Nov 2024 05:06:05 -0500 Received: from mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:4f43:0:640:673c:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id A80DD60F16; Mon, 18 Nov 2024 13:05:56 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id s5NW0wbOfSw0-PpDw98Pr; Mon, 18 Nov 2024 13:05:56 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731924356; bh=j5OaP+9DauQyTpV/xilFPb7/iZxQKmcTlhoAHpe/6ho=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=T7iTNaxFzWCdvZdVyCsMcz0joqKDLc8P3c0fEOCKdmMJp5D5Wy88XPeuO/feQmV+k yjVGnyo0iQdJ4u7ph01HSD3tukJUzZAwCwb1g1PWTwB+lg0jY+kdinyyh/3koTfBwh Uua+P3tq/3acdXctPrOTR6SrD7DE/sEUN23xj2QE= Authentication-Results: mail-nwsmtp-smtp-production-main-24.klg.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> From: Konstantin Kharlamov Date: Mon, 18 Nov 2024 13:05:54 +0300 In-Reply-To: References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On Mon, 2024-11-18 at 05:06 +0100, Gerd M=C3=B6llmann wrote: > Konstantin Kharlamov writes: >=20 > > Even Gerd in this discussion forgot about this peculiarity =E2=80=94 an= d > > Gerd unlike me is a regular Emacs developer. >=20 > Even worse, even worse: He wrote that stuff! But I think I'll excuse > him > because that was 25 years ago, and he took a 20 year break from > Emacs, > after stepping down, and he's old of course :-). >=20 > Seriously, maybe knowing a bit of history helps understand the > current > situation wrt .elc files? One wouldn't believe it nowadays, but they > were originally in version control, i.e. RCS, and later CVS. I didn't > want that in the public CVS repo we set up for Emacs 21, so I added > the > ability to bootstrap and removed the .elc files from CVS. > COMPILE_FIRST > and so on are part of the bootstrapping support. Btw, thank you, this bit of history indeed is interesting. During whole discussion I had a question on the back of my mind: how this "distribute pre-built elc in tarballs" idea initially came to be. I mean, it's kind of nice from POV of saving a bit of energy around the world on CI machines, but I don't see much beyond that. Building elc files is not *that* bad for elc distribution to be strictly necessary. Now that you told this, I realize it's just a solution to a problem from 25 years old back, from times when that actually was a problem. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 13:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17319347542277 (code B ref 74382); Mon, 18 Nov 2024 13:00:02 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 12:59:14 +0000 Received: from localhost ([127.0.0.1]:60470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1LW-0000af-CY for submit@debbugs.gnu.org; Mon, 18 Nov 2024 07:59:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1LU-0000aR-7E for 74382@debbugs.gnu.org; Mon, 18 Nov 2024 07:59:13 -0500 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 1tD1LO-0006YM-O6; Mon, 18 Nov 2024 07:59:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0CE9Qm576y7ZeM6LZqkZBTG+VdkGc0GVf2mjiI0y+G8=; b=SHq6RLyiCCiT Dlb0PSFS1diI50UmrFBVpLZMpIvqPt9CrFnGSO5UPVHmY0UgoOeDfNKtZfOsbqc5qcBgB78KWdbXJ H16kfFufrU6a16KpJizHURfckN4aWwS+EFwcFPZkXtABy3E84pxNjtZspOWXpECNnljSBJ0EgDCKP kyKJyu+0xBrc7DZSK3qoeOWrFOAPomSPPhhI/bOTxiHM6NTcsY4AjikBT5M7nwc1An0qBKY13uwUR A0SDaVfX+XQg0kE+1llvOz0qGKF2XmF5p40v3QkzyCBGlfKugF0YZDJuSThL3+lOs943A6KhZ/rpE qo16TPMiamaTCBXEgC4PKQ==; Date: Mon, 18 Nov 2024 14:59:00 +0200 Message-Id: <86cyisvgtn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> (message from Konstantin Kharlamov on Mon, 18 Nov 2024 13:05:54 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> 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: Konstantin Kharlamov > Cc: Eli Zaretskii , acm@muc.de, 74382@debbugs.gnu.org > Date: Mon, 18 Nov 2024 13:05:54 +0300 > > Btw, thank you, this bit of history indeed is interesting. During whole > discussion I had a question on the back of my mind: how this > "distribute pre-built elc in tarballs" idea initially came to be. I > mean, it's kind of nice from POV of saving a bit of energy around the > world on CI machines, but I don't see much beyond that. Building elc > files is not *that* bad for elc distribution to be strictly necessary. Once again, building all the *.elc files takes a long time, even on modern systems. I have a 32-core screamer, and it still takes a few minutes to byte-compile everything. On an older system, it used to take me 15 minutes even in parallel (-j4) builds. Computers got much faster, but people know that, so they have less patience. Thus, avoiding recompilation of the *.elc files (and Info, and other derived files) is still important to make the build faster. A release tarball builds in less than 1 min due to these measures. > Now that you told this, I realize it's just a solution to a problem > from 25 years old back, from times when that actually was a problem. I don't understand this conclusion. What problem existed 25 years ago that is related to "make clean" or to load-prefer-newer, and doesn't exist anymore? From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 13:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17319356394992 (code B ref 74382); Mon, 18 Nov 2024 13:14:01 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 13:13:59 +0000 Received: from localhost ([127.0.0.1]:60497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1Zn-0001IR-3z for submit@debbugs.gnu.org; Mon, 18 Nov 2024 08:13:59 -0500 Received: from forward500d.mail.yandex.net ([178.154.239.208]:41002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1Zk-0001ID-2D for 74382@debbugs.gnu.org; Mon, 18 Nov 2024 08:13:58 -0500 Received: from mail-nwsmtp-smtp-production-main-77.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-77.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:81af:0:640:7b5c:0]) by forward500d.mail.yandex.net (Yandex) with ESMTPS id 1CBBE6001A; Mon, 18 Nov 2024 16:13:19 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-77.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id HDQsnTdOl0U0-FXfOftAr; Mon, 18 Nov 2024 16:13:18 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1731935598; bh=dmtXXsXqgDm4NbDcFVS3gJmWUuNjqBSLLiREH368v48=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=Lz1j4ldkoSNl8Hq8S6k92l8WhvQGrHV5BFMD+HWwRYgE7zVOXtkkgbFnEpaimaaxR Mnu9oGQnm83DQRyYoSK73EfiML9AIbEAAXL4YSsrgu0/8KZV6upizuy7qb9braYmk8 KWpAP2j5mCd5gAEdetmSZZdYOFoDms0q6151hNdk= Authentication-Results: mail-nwsmtp-smtp-production-main-77.klg.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <786ad13ce69b0a809148cd5d43d6518296ad1015.camel@yandex.ru> From: Konstantin Kharlamov Date: Mon, 18 Nov 2024 16:12:08 +0300 In-Reply-To: <86cyisvgtn.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> <86cyisvgtn.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 X-Spam-Score: -0.7 (/) 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: -1.7 (-) On Mon, 2024-11-18 at 14:59 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: Eli Zaretskii , acm@muc.de, 74382@debbugs.gnu.org > > Date: Mon, 18 Nov 2024 13:05:54 +0300 > >=20 > > Btw, thank you, this bit of history indeed is interesting. During > > whole > > discussion I had a question on the back of my mind: how this > > "distribute pre-built elc in tarballs" idea initially came to be. I > > mean, it's kind of nice from POV of saving a bit of energy around > > the > > world on CI machines, but I don't see much beyond that. Building > > elc > > files is not *that* bad for elc distribution to be strictly > > necessary. >=20 > Once again, building all the *.elc files takes a long time, even on > modern systems.=C2=A0 I have a 32-core screamer, and it still takes a few > minutes to byte-compile everything.=C2=A0 On an older system, it used to > take me 15 minutes even in parallel (-j4) builds. >=20 > Computers got much faster, but people know that, so they have less > patience.=C2=A0 Thus, avoiding recompilation of the *.elc files (and Info= , > and other derived files) is still important to make the build faster. > A release tarball builds in less than 1 min due to these measures. 3 and even 15 minutes of compilation once a few months at worst (the time between Emacs releases) is not a big deal. Besides, the endusers don't typically compile releases, instead distro packagers do that, and they are typically using CI. Emacs by far is not the slowest project to compile from scratch. AFAIR LibreOffce and Linux Kernel take longer to build. > > Now that you told this, I realize it's just a solution to a problem > > from 25 years old back, from times when that actually was a > > problem. >=20 > I don't understand this conclusion.=C2=A0 What problem existed 25 years > ago > that is related to "make clean" or to load-prefer-newer, and doesn't > exist anymore? This is tangentially related to `make clean` discussoin. I was just curious how come that Emacs started distributing elc files in release tarballs. Like, was there someone who asked for that, or anything=E2=80=A6 = Now I see it's just a feature from long past. I am not saying it's bad or good, because that's a separate question (there are both pros and cons). From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Nov 2024 13:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Konstantin Kharlamov Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17319371259474 (code B ref 74382); Mon, 18 Nov 2024 13:39:02 +0000 Received: (at 74382) by debbugs.gnu.org; 18 Nov 2024 13:38:45 +0000 Received: from localhost ([127.0.0.1]:60535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1xk-0002Sj-Ib for submit@debbugs.gnu.org; Mon, 18 Nov 2024 08:38:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tD1xh-0002SS-6x for 74382@debbugs.gnu.org; Mon, 18 Nov 2024 08:38:42 -0500 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 1tD1xb-0004eM-86; Mon, 18 Nov 2024 08:38:35 -0500 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=xdRD6hsVHnk13rvsoDeA//4n2MLBNinEH4I+QBMU1PM=; b=nB6m3pn+hpJDrwURqY/z ZeyaX1k7FLZ0BMV9VvfZ2DX6rvj1LXjeRvVYpCvC42ScyGKK2VNVQZjeIiDjdcA1ml+u8KfrvoBb3 NXJ4FXz/PdPg2EEkaxv5kTG06Ib9B/RvObBIQgvwR9ScmolOaOzxxUMMorjUiLzwqGQeP349DrSwE rdGyJ8AhhqndXhWo5xo3DRb2porPLNx+Mr1P5bS0CElS95WEaRi1MsCmOWeuVaNGQMjDB/mZ7yIKF 422/aqWJs5O2GGSsxpHx8jiZ/5V5530sGsYqaNiKvNl+TWaYJu3+XI4EHom+4NxwK74z/PVgAbvuR mpuhxDl6yfTTPQ==; Date: Mon, 18 Nov 2024 15:38:31 +0200 Message-Id: <86a5dwvezs.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <786ad13ce69b0a809148cd5d43d6518296ad1015.camel@yandex.ru> (message from Konstantin Kharlamov on Mon, 18 Nov 2024 16:12:08 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> <86cyisvgtn.fsf@gnu.org> <786ad13ce69b0a809148cd5d43d6518296ad1015.camel@yandex.ru> 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: Konstantin Kharlamov > Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org > Date: Mon, 18 Nov 2024 16:12:08 +0300 > > > Once again, building all the *.elc files takes a long time, even on > > modern systems.  I have a 32-core screamer, and it still takes a few > > minutes to byte-compile everything.  On an older system, it used to > > take me 15 minutes even in parallel (-j4) builds. > > > > Computers got much faster, but people know that, so they have less > > patience.  Thus, avoiding recompilation of the *.elc files (and Info, > > and other derived files) is still important to make the build faster. > > A release tarball builds in less than 1 min due to these measures. > > 3 and even 15 minutes of compilation once a few months at worst (the > time between Emacs releases) is not a big deal. Besides, the endusers > don't typically compile releases, instead distro packagers do that, and > they are typically using CI. That's your opinions, not mine. From my POV, having these files in the tarball makes the build much faster and also much more reliable and correct. That means a lot, even if you don't value that. > Emacs by far is not the slowest project to compile from scratch. AFAIR > LibreOffce and Linux Kernel take longer to build. So we are supposed to judge ourselves by the lowest common denominator? > This is tangentially related to `make clean` discussoin. I was just > curious how come that Emacs started distributing elc files in release > tarballs. Any project that doesn't distribute platform-independent files in its tarball does a disservice to its users. There's absolutely no reason not to include them, and more than one to include: time it takes to build them, tools required for building them that are otherwise not needed, etc. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2024 12:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Hi-Angel@yandex.ru Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.17335727571417 (code B ref 74382); Sat, 07 Dec 2024 12:00:02 +0000 Received: (at 74382) by debbugs.gnu.org; 7 Dec 2024 11:59:17 +0000 Received: from localhost ([127.0.0.1]:45608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJtSu-0000Mk-HW for submit@debbugs.gnu.org; Sat, 07 Dec 2024 06:59:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tJtSs-0000ML-Dt; Sat, 07 Dec 2024 06:59:15 -0500 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 1tJtSn-0005Zu-4E; Sat, 07 Dec 2024 06:59:09 -0500 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=UukzxK3VohD1a3Y5gbGaxn7fFY6FWFIOXJ6zjuytruk=; b=NQijxCgu8M4cIWHI0cAz wb3K2gvp3SNgQJ/9TexOUjBuFSmo1J6e0vjqfnU9x+Q98Po/CUq8qhtR0hpLrqiF8lBxoZmN1Vyqe 2bHLB/Vt8pLvnaqY48Bi2R4t7MwepUhHSNNddZRQB0OSr06rWlum51fnU7gRhSnE4/G5QXwQUQujN gGIBAHcSu3R0x+dwu51dIhlx2AjOJmEn2R54iRUpqQjU87tx7e/ggXr4ZZjamV20YBKddLhOfcBD+ q8iXrdjgpUn6KJ2tzNFOmjFOw9BMdUbZm5FLp1QA+k5aCsI/CZvPq8WpwHP3on5ndICec4Q+5ufZU SpHuo6wzQ8sTOg==; Date: Sat, 07 Dec 2024 13:58:56 +0200 Message-Id: <86ed2jk8lb.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86a5dwvezs.fsf@gnu.org> (message from Eli Zaretskii on Mon, 18 Nov 2024 15:38:31 +0200) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <31dfd7d1c1c19d3fff5609b86ce85c1533a84af0.camel@yandex.ru> <861pz9x45w.fsf@gnu.org> <86zflxvoux.fsf@gnu.org> <7b07de9fd995f14e3b4d675c7288108dbe57209c.camel@yandex.ru> <86cyisvgtn.fsf@gnu.org> <786ad13ce69b0a809148cd5d43d6518296ad1015.camel@yandex.ru> <86a5dwvezs.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 (---) tags 74382 notabug close 74382 thanks > Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org > Date: Mon, 18 Nov 2024 15:38:31 +0200 > From: Eli Zaretskii > > > From: Konstantin Kharlamov > > Cc: gerd.moellmann@gmail.com, 74382@debbugs.gnu.org > > Date: Mon, 18 Nov 2024 16:12:08 +0300 > > > > > Once again, building all the *.elc files takes a long time, even on > > > modern systems.  I have a 32-core screamer, and it still takes a few > > > minutes to byte-compile everything.  On an older system, it used to > > > take me 15 minutes even in parallel (-j4) builds. > > > > > > Computers got much faster, but people know that, so they have less > > > patience.  Thus, avoiding recompilation of the *.elc files (and Info, > > > and other derived files) is still important to make the build faster. > > > A release tarball builds in less than 1 min due to these measures. > > > > 3 and even 15 minutes of compilation once a few months at worst (the > > time between Emacs releases) is not a big deal. Besides, the endusers > > don't typically compile releases, instead distro packagers do that, and > > they are typically using CI. > > That's your opinions, not mine. From my POV, having these files in > the tarball makes the build much faster and also much more reliable > and correct. That means a lot, even if you don't value that. > > > Emacs by far is not the slowest project to compile from scratch. AFAIR > > LibreOffce and Linux Kernel take longer to build. > > So we are supposed to judge ourselves by the lowest common > denominator? > > > This is tangentially related to `make clean` discussoin. I was just > > curious how come that Emacs started distributing elc files in release > > tarballs. > > Any project that doesn't distribute platform-independent files in its > tarball does a disservice to its users. There's absolutely no reason > not to include them, and more than one to include: time it takes to > build them, tools required for building them that are otherwise not > needed, etc. No further comments, so I'm closing this bug. From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Dec 2024 11:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173391599631051 (code B ref 74382); Wed, 11 Dec 2024 11:20:01 +0000 Received: (at 74382) by debbugs.gnu.org; 11 Dec 2024 11:19:56 +0000 Received: from localhost ([127.0.0.1]:33214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLKl2-00084k-A5 for submit@debbugs.gnu.org; Wed, 11 Dec 2024 06:19:56 -0500 Received: from forward501b.mail.yandex.net ([178.154.239.145]:54306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLKkz-00083y-8b for 74382@debbugs.gnu.org; Wed, 11 Dec 2024 06:19:54 -0500 Received: from mail-nwsmtp-smtp-production-main-25.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-25.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:992:0:640:7835:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id 856176153E; Wed, 11 Dec 2024 14:19:46 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-25.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id jJljuEFOha60-fCNj4G8b; Wed, 11 Dec 2024 14:19:46 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1733915986; bh=qsJVhDBs0wi7rd7Bda/vjjWiArAJLIUInEfHrLE7w1o=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=PmpDFoKeFa/0Q/hbl/0G2LKi0IToLHMsrCxaWvj3ck9VygQnm9e2JqJLNSeyHQ48Q Byc+vLPZ5x2MQ0d/3TJSBuYJ7VU+RrS7K/BZJ0Xs0ZM5+bZ3UkHyrwxr03I1Dr+Itk V3gcsWHHgapGmlkWkdfZYhPkToaEYfb89TTn6YrY= Authentication-Results: mail-nwsmtp-smtp-production-main-25.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <6f35390cfd212027cf67fd697dcdc9c1a5ec6edc.camel@yandex.ru> From: Konstantin Kharlamov Date: Wed, 11 Dec 2024 14:19:45 +0300 In-Reply-To: <86y11jf8kd.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86y11jf8kd.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) On related note, I am wondering if it may be better to compile `COMPILE_FIR= ST` files all at once? I haven't found any robust way to measure building time of COMPILE_FIRST-on= ly files as part of the build system, via some sort of invocation like `make -C lisp SOMETHING`. So instead I tested by invoking buliding command manually from the `build/l= isp` dir like they would be invoked by Make. And I found x2.5 improvement in build t= ime! Testing old behavior: $ find ../../ -type f -name "*.elc" -delete $ time for f in ../../lisp/emacs-lisp/macroexp.el ../../lisp/emacs-lisp= /cconv.el ../../lisp/emacs-lisp/byte-opt.el ../../lisp/emacs-lisp/bytecomp.= el ../../lisp/emacs-lisp/comp.el ../../lisp/emacs-lisp/comp-cstr.el ../../l= isp/emacs-lisp/comp-common.el ../../lisp/emacs-lisp/comp-run.el; do ../src/= bootstrap-emacs -batch --no-site-file --no-site-lisp -l comp -f batch-byte-= compile $f; done real 1m38.932s user 1m38.684s sys 0m0.116s Testing "compile all at once": $ find ../../ -type f -name "*.elc" -delete $ time ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp -l c= omp -f batch-byte-compile ../../lisp/emacs-lisp/macroexp.el ../../lisp/emac= s-lisp/cconv.el ../../lisp/emacs-lisp/byte-opt.el ../../lisp/emacs-lisp/byt= ecomp.el ../../lisp/emacs-lisp/comp.el ../../lisp/emacs-lisp/comp-cstr.el .= ./../lisp/emacs-lisp/comp-common.el ../../lisp/emacs-lisp/comp-run.el real 0m39.970s user 0m39.896s sys 0m0.024s From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Dec 2024 11:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173391610531897 (code B ref 74382); Wed, 11 Dec 2024 11:22:01 +0000 Received: (at 74382) by debbugs.gnu.org; 11 Dec 2024 11:21:45 +0000 Received: from localhost ([127.0.0.1]:33222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLKmm-0008IJ-TP for submit@debbugs.gnu.org; Wed, 11 Dec 2024 06:21:45 -0500 Received: from forward502a.mail.yandex.net ([178.154.239.82]:47940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLKml-0008Ho-Jf for 74382@debbugs.gnu.org; Wed, 11 Dec 2024 06:21:44 -0500 Received: from mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1d:3d20:0:640:8692:0]) by forward502a.mail.yandex.net (Yandex) with ESMTPS id 6A05C60CBA; Wed, 11 Dec 2024 14:21:07 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 6Ll1kpFOcqM0-jRJQV6WN; Wed, 11 Dec 2024 14:21:07 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1733916067; bh=IUDjBZIqVrk4v2Bq4hABrsftXYfwTqfbDFWR2ePeMs8=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=fiGa5YLD7zgFl0p2FhF9OudS5srFAGzengK2VmXMGZ1kMGFeUZau7nJcsEQ5f5hSI xcrDYtoJR5Hj0NrXcXgnGYiOooXKZ27hZvvYpgRVygTRz09fbfD9XgWX0HvduFMNxE xkHsbNsW/ShcyuJtiwrkJdETuaVAwhjKpvj01fTw= Authentication-Results: mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: From: Konstantin Kharlamov Date: Wed, 11 Dec 2024 14:21:06 +0300 In-Reply-To: <86y11jf8kd.fsf@gnu.org> References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86y11jf8kd.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 MIME-Version: 1.0 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: -1.0 (-) (sorry, forgot to click "reply all", resending) On related note, I am wondering if it may be better to compile `COMPILE_FIR= ST` files all at once? I haven't found any robust way to measure building time of COMPILE_FIRST-on= ly files as part of the build system, via some sort of invocation like `make -C lisp SOMETHING`. So instead I tested by invoking buliding command manually from the `build/l= isp` dir like they would be invoked by Make. And I found x2.5 improvement in build t= ime! Testing old behavior: $ find ../../ -type f -name "*.elc" -delete $ time for f in ../../lisp/emacs-lisp/macroexp.el ../../lisp/emacs-lisp= /cconv.el ../../lisp/emacs-lisp/byte-opt.el ../../lisp/emacs-lisp/bytecomp.= el ../../lisp/emacs-lisp/comp.el ../../lisp/emacs-lisp/comp-cstr.el ../../l= isp/emacs-lisp/comp-common.el ../../lisp/emacs-lisp/comp-run.el; do ../src/= bootstrap-emacs -batch --no-site-file --no-site-lisp -l comp -f batch-byte-= compile $f; done real 1m38.932s user 1m38.684s sys 0m0.116s Testing "compile all at once": $ find ../../ -type f -name "*.elc" -delete $ time ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp -l c= omp -f batch-byte-compile ../../lisp/emacs-lisp/macroexp.el ../../lisp/emac= s-lisp/cconv.el ../../lisp/emacs-lisp/byte-opt.el ../../lisp/emacs-lisp/byt= ecomp.el ../../lisp/emacs-lisp/comp.el ../../lisp/emacs-lisp/comp-cstr.el .= ./../lisp/emacs-lisp/comp-common.el ../../lisp/emacs-lisp/comp-run.el real 0m39.970s user 0m39.896s sys 0m0.024s From unknown Fri Aug 15 18:13:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74382: `compile-first` Make rule is no longer using `load-prefer-newer` Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Dec 2024 15:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74382 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Konstantin Kharlamov Cc: acm@muc.de, 74382@debbugs.gnu.org Received: via spool by 74382-submit@debbugs.gnu.org id=B74382.173393168230906 (code B ref 74382); Wed, 11 Dec 2024 15:42:01 +0000 Received: (at 74382) by debbugs.gnu.org; 11 Dec 2024 15:41:22 +0000 Received: from localhost ([127.0.0.1]:35763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLOq2-00082O-9V for submit@debbugs.gnu.org; Wed, 11 Dec 2024 10:41:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tLOpz-000824-Tn for 74382@debbugs.gnu.org; Wed, 11 Dec 2024 10:41:20 -0500 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 1tLOpt-00021w-MC; Wed, 11 Dec 2024 10:41:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4WwzQwfiuSoaCbQFom2/SZ6tA/1nOavKDviqtsQ0Clc=; b=FiBLircnuyy/ UvqxIsjzPM6UamXV0mNmSD5YXM+xMXjgLybyF8E4jL+/SJx3uzofpuZtZzzR+hy26UNLmULyOx8vZ R5+gHYVH7FGuqpSrC7S/lcxXAeozfGXFGZmnHvVQ+dD6Ut8Wu+iyRmcyqSspSIUWP3KRrESs5vTNK qwCjLYSCkPrDqzllH8HQ8h74t3WoJPub5ZOz4tTq0FPub2MpvQVBZ34blSfVKcIggk5iNglezkzY7 IebhD1/08p3qjBYBK2MQZ1gjLfWdo7Faatli4NuRXZ90gvtpmzA/+wQgcqMjbsK920p9bUxfgO4sR BOuidoQCcBlyWjgxl69+xA==; Date: Wed, 11 Dec 2024 17:41:08 +0200 Message-Id: <86y10m2pnv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <6f35390cfd212027cf67fd697dcdc9c1a5ec6edc.camel@yandex.ru> (message from Konstantin Kharlamov on Wed, 11 Dec 2024 14:19:45 +0300) References: <6bc3a410f0857c3e3433070ac19deaf7eae88c63.camel@yandex.ru> <86y11jf8kd.fsf@gnu.org> <6f35390cfd212027cf67fd697dcdc9c1a5ec6edc.camel@yandex.ru> 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: Konstantin Kharlamov > Cc: 74382@debbugs.gnu.org, acm@muc.de > Date: Wed, 11 Dec 2024 14:19:45 +0300 > > On related note, I am wondering if it may be better to compile > `COMPILE_FIRST` files all at once? This has the disadvantage of letting every file you compile inherit the session into which the previous files were loaded, so they could be adversely affected. For example, missing 'require's could be missed, because the previous file already loaded them. And there are more problems like that. So we prefer to compile each file in a fresh Emacs session.