From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Date: Tue, 11 Apr 2023 11:03:34 +0300 Message-ID: <83zg7ealrd.fsf@gnu.org> References: <17b74a48-94e1-9106-cc79-d31972313910@gutov.dev> <837cujaqzq.fsf@gnu.org> <87wn2ilwed.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bzg@gnu.org, dmitry@gutov.dev, 62762@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 11 10:03:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pm8yI-00019a-2J for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 10:03:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pm8y1-0000dH-66; Tue, 11 Apr 2023 04:03:05 -0400 Original-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 1pm8xz-0000d1-2s for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 04:03:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pm8xy-000150-D5 for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 04:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pm8xy-0001Kx-0I for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 04:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 08:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62762 X-GNU-PR-Package: emacs Original-Received: via spool by 62762-submit@debbugs.gnu.org id=B62762.16812001815135 (code B ref 62762); Tue, 11 Apr 2023 08:03:01 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 08:03:01 +0000 Original-Received: from localhost ([127.0.0.1]:36539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pm8xw-0001Ki-Vx for submit@debbugs.gnu.org; Tue, 11 Apr 2023 04:03:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pm8xv-0001KT-2D for 62762@debbugs.gnu.org; Tue, 11 Apr 2023 04:02:59 -0400 Original-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 1pm8xp-00014Z-7m; Tue, 11 Apr 2023 04:02:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MrwNIaXpuKtWey1qbjeIKfdJPssowpmlM4B9kenuXDQ=; b=fYyryRD/Cy5B rIQfEXvKlCgXVvICOOUbKTlTTcxGIXFMu8mWKEfVwU3hkItQxeO85rSt4Rry456nnXPjN/ZGcDQSu Dw00z2y3TkfacYQ2dmWOHqk6bOX2VtuAiH1PN38kbb5EXQRXGyH+sPYxE+PnCQcgh1XciIzTIC1Lj 9ESKpmf4MCX3PIMHQ7uJumWMFiELrJVpNy4W8MVEQLpq7zffiTFTx8AfBfyb6SfGshuwKOlGNHh4n 1ZnAJMyrYFZbxLJxBbRia68G2dW4k9UywP6eqxOrn/i4jEHn0sDTNrZqg7VgBocL/WH4Qcl1NYn/N 8DemODuhIr8I9bPfyp1fsg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pm8xo-0006tY-4D; Tue, 11 Apr 2023 04:02:52 -0400 In-Reply-To: <87wn2ilwed.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 07:18:18 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259627 Archived-At: > From: Ihor Radchenko > Cc: Dmitry Gutov , Bastien , > 62762@debbugs.gnu.org > Date: Tue, 11 Apr 2023 07:18:18 +0000 > > Eli Zaretskii writes: > > > Or maybe Org folks (CC'ed) could suggest a better fix. I understand > > the reasons for this behavior in Org, but none of the reasons > > described in org-version.el are relevant to Emacs development, when a > > new version of Org is merged. Maybe the abort could be augmented not > > to produce such a drastic effect? > > The fact the Org error is triggered means that Emacs does not re-compile > .el files that refer to macros that have been changed. You know this is not really possible in Emacs. > Macros not being updated, as one may expect, may break the code using > old macro expansions. So, I cannot say that Org is wrong complaining > about mismatch here. In fact, we already made the check less strict to > work around the same issue on ELPA. See > https://list.orgmode.org/orgmode/87r10ey8ov.fsf@localhost/ and > https://list.orgmode.org/orgmode/87pmfijrvw.fsf@localhost/ How is this different from any other Lisp file in Emacs? We have quite a few that define macros used elsewhere, and we rely on byte-compilation during the build to tell us when the old definitions get in the way. We don't forcefully abort the build, just because problems _might_ exist. And people who want to make sure their builds are 110% perfect always bootstrap to begin with. Building a tarball also requires a bootstrap, so the chance of these issues slipping through cracks are minuscule to say the least. Anyway, any other words of wisdom? Like which org/*.el files actually need to be recompiled in this case? Or are you saying all of them need to be recompiled? I also am not sure I understand the logic of this test: AFAIU it only tests the version string, not the actual macros that might have been changed. Are you saying that Org bumps its version string each time _any_ Org macro is modified? Also, how about the alternative of including the version string in every Org Lisp file that needs to be recompiled when the version changes (or the macros change)? Then recompilation will happen automatically, and this problem will go away. Does this make sense? > Maybe make bootstrap is justified then? No, it isn't. Not unless files outside of lisp/org/ will start importing org-version.el. > Of course, ideally, Emacs should provide a way to handle macro dependencies. Ideally, this would be a much nicer world, indeed. But humanity was expelled from the Garden of Eden long ago, so here we are.