From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 18:35:51 +0000 Message-ID: <87pm8a8dx4.fsf@localhost> References: <17b74a48-94e1-9106-cc79-d31972313910@gutov.dev> <837cujaqzq.fsf@gnu.org> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1205"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bzg@gnu.org, dmitry@gutov.dev, 62762@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 11 20:34:23 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 1pmIov-000Aco-VN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 20:34:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmIoe-0007cb-Ap; Tue, 11 Apr 2023 14:34:04 -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 1pmIoc-0007cS-VL for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:34: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 1pmIoc-0007mb-CX for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmIob-0005fq-I9 for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 18:34: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.168123801221775 (code B ref 62762); Tue, 11 Apr 2023 18:34:01 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 18:33:32 +0000 Original-Received: from localhost ([127.0.0.1]:38190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmIo8-0005f7-0L for submit@debbugs.gnu.org; Tue, 11 Apr 2023 14:33:32 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:42023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmIo5-0005eu-0u for 62762@debbugs.gnu.org; Tue, 11 Apr 2023 14:33:30 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 513FA24033E for <62762@debbugs.gnu.org>; Tue, 11 Apr 2023 20:33:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681238003; bh=jJEPBhk38njvumiV9PBGbyTsc5Ze8rFB+ti7UXmiRDc=; h=From:To:Cc:Subject:Date:From; b=CW10xOJ1nytnGb4nJCm8JBJ2k1qG9ofEd/J//LjR6ywavEQaul4/4bt9ijWcSU5Dw IEYN91Zpzg1mL+kkfvZ57vIoTWu2zEddkJPPPhMz0wkXAMWSjKWpZgk3UkxNvjcaK6 TRttXejV1XK6NK+SMMYbbUKg57ew5zRlT1AUcQirLBg/r4D2FYgi6T78LG0QTYQZRg 0/gEPfZVAPws+4aZDNtnGGqP9kAigII3r0EgVc+asyyHhbcH50gUollK6n62RSQCgX a5/MSJult40c7EGobwMZbCqDYBLaQbu0l6hPhSiWXVRkYk837Fs9TOIEj/pcEkXQZV y/ctm2MGfl1TQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pwvc23VCzz9rxX; Tue, 11 Apr 2023 20:33:22 +0200 (CEST) In-Reply-To: <83zg7ealrd.fsf@gnu.org> 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:259661 Archived-At: Eli Zaretskii writes: >> 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. I don't. Say, why not to store hash of the macro sources in the byte code and verifying the hash when re-compilation is requested? Though I am not that much familiar with Emacs source compilation. >> 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. Sure, in the context of Emacs compilation. The code in question is mostly aiming at newer Org installed on top of built-in Org. We are consistently getting issues related to incorrect macro expansion and mixing different Org versions. > 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? All of them, because org-assert-version expands into (unless (equal "version string" (org-release)) ...) at compile time. "Version string" contains the return value of (org-release) for the time the .elc file is compiled. Note that the reported issue will only happen when Org version string changes between the builds. What we might do to work around the problem is detecting Emacs compilation and disable the check. Is there a way to detect that Emacs source is being compiled from Elisp? > 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? No. We originally tested by commit hash. Version string check is a trade-off between the problem with ELPA builds (see the links in my previous message) and the need to detect mixed installation problems. > 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? No. We will not be able to maintain this manually. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at