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 21:51:04 +0300 Message-ID: <8335569rs7.fsf@gnu.org> References: <17b74a48-94e1-9106-cc79-d31972313910@gutov.dev> <837cujaqzq.fsf@gnu.org> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@gnu.org> <87pm8a8dx4.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8958"; 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 20:51:34 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 1pmJ5Y-00028b-MW for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Apr 2023 20:51:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmJ5A-0000mT-L3; Tue, 11 Apr 2023 14:51:08 -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 1pmJ55-0000ly-GC for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:51: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 1pmJ55-0002t2-3S for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmJ54-0006Cg-Vt for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:51: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 18:51:02 +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.168123903123618 (code B ref 62762); Tue, 11 Apr 2023 18:51:02 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 18:50:31 +0000 Original-Received: from localhost ([127.0.0.1]:38209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJ4Y-00068r-R8 for submit@debbugs.gnu.org; Tue, 11 Apr 2023 14:50:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJ4W-000684-Dx for 62762@debbugs.gnu.org; Tue, 11 Apr 2023 14:50:29 -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 1pmJ4Q-0002rJ-1a; Tue, 11 Apr 2023 14:50:22 -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=Cy2Iw5RV8yrfkXgBS7LXZ+SHdgoZFZZ9EQq+aCJAMnM=; b=T9k0ZSZ9f6m1 E+gSU0pxiLlwM4QV/1DtuEFjYxv5ZIVCDjzi8jHmBvdgthuJtc8GxfXutp1Ox4hIQR6B2DDmxM3De D1SUlIK8HP+BerOH1ttSFhxWGd1n9ocDZkNauVY9DJ1Fm3irf+b73dwCvJKp1IjaWIMmimNx0Cu0z UaOzoosw5wIGT2vMYK8cS7ZPjTgH+GW5CgtZutkc+oEU/NDYHFlE+w6Bly7zoHKVfbQXl3NhImnih HdxmEMOa/btK7AnKKp9YOEmy2dbmOJbka8yp7t9HwH3BOe1JCvjXjw5aaeEietV5+J8H2N1tWsk70 VEWGj2RaAglDaTSMwQo9sg==; 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 1pmJ4P-0000rw-31; Tue, 11 Apr 2023 14:50:21 -0400 In-Reply-To: <87pm8a8dx4.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 18:35:51 +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:259664 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, bzg@gnu.org, 62762@debbugs.gnu.org > Date: Tue, 11 Apr 2023 18:35:51 +0000 > > 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. We need to do this the "make" way. That is, we need to be able to produce dependencies that Make can understand, e.g. similarly to how the *.d files in src/.deps are produced by GCC. This is in principle possible, but we need changes in the byte compiler and in 'load', and probably more. > Note that the reported issue will only happen when Org version string > changes between the builds. Which happened twice during the last week or two, AFAIR. Moreover, it happens on almost every branch, and if someone builds several branches routinely (I do), the annoyance happens several times in a row. > 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? Not sure I understand: the byte compiler is a Lisp program, so every compilation is "from Lisp", no? Or what am I missing? > > 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. I guess it means we are on our own, sigh...