From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Max Nikulin Newsgroups: gmane.emacs.bugs Subject: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Date: Thu, 4 May 2023 22:31:43 +0700 Message-ID: <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@gmail.com> References: <17b74a48-94e1-9106-cc79-d31972313910@gutov.dev> <837cujaqzq.fsf@gnu.org> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@gnu.org> <87pm8a8dx4.fsf@localhost> <87pm7vt0mx.fsf@localhost> <87cz3k8i27.fsf@localhost> <87sfcfdldt.fsf@localhost> <87bkj1g10g.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21250"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: bzg@gnu.org, dmitry@gutov.dev, Eli Zaretskii , 62762@debbugs.gnu.org, Alan Mackenzie To: Ihor Radchenko , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 04 17:43:08 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 1pub6q-0005El-46 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 May 2023 17:43:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pub6i-0005um-I0; Thu, 04 May 2023 11:43:00 -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 1puay2-0003Pd-Dj for bug-gnu-emacs@gnu.org; Thu, 04 May 2023 11:34:02 -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 1puay2-0000O9-4r for bug-gnu-emacs@gnu.org; Thu, 04 May 2023 11:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1puay1-00054L-Ri for bug-gnu-emacs@gnu.org; Thu, 04 May 2023 11:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Max Nikulin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 May 2023 15: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.168321439719408 (code B ref 62762); Thu, 04 May 2023 15:34:01 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 4 May 2023 15:33:17 +0000 Original-Received: from localhost ([127.0.0.1]:51850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puaxJ-00052y-Ab for submit@debbugs.gnu.org; Thu, 04 May 2023 11:33:17 -0400 Original-Received: from mail-lj1-f179.google.com ([209.85.208.179]:46172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puaxH-00052h-2C for 62762@debbugs.gnu.org; Thu, 04 May 2023 11:33:16 -0400 Original-Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2a8b1b51dbdso7743381fa.0 for <62762@debbugs.gnu.org>; Thu, 04 May 2023 08:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683214389; x=1685806389; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=E43QJyFgKlksTNYa+ZGSbgfP2uIwttrkDcRQBuIEglQ=; b=XoNu4gZxQcn2BhMrTd8hFwMHeTN/d/0LDLzg1GCMIRawIsHKKLPFN9rxyS4DP8yrsn 7IWJkd1NSg1HRrX7GrBsNS459dtsAACIx/FAckcKA2kTxcYQgNhaC+3oYo4bEhQkRXvR 8N94IoMEkBrudWsipp2Cc6MvdxtHXr33ZLdkICyXzFn39y+uEqb08+EPUZhKAaNjba1Z Fgg6oXlQ7t4zAnNj2jLCIk9mslOv7hv83zJutwx+KEGMqtX1LPB3yPbIF9RfLMOP9206 PHOz1sckF7XdorniUIeqRip0v1qsTNf6PuxkRfHd64Z9cRVUcwjFMXOKFKKZnr1kPzYN 2mmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683214389; x=1685806389; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E43QJyFgKlksTNYa+ZGSbgfP2uIwttrkDcRQBuIEglQ=; b=OoBrJ82qRNGQUGkbvS2mW6ZzIQzgUmCSvBvMUOnskjXGHngCgscdvNKbeIrj3ECBvz SP5xdo190Od7LteeEHm65sAGWEAVct1Jat+3ed75BYR66m8ZPvkMyfw7cU/p9HS0V3sB CVgfpgio/iUKsgvIBi5XcRuICjizi0tvbKccIJc/a4S2/w6+ifidjUcVq3yvMBhc/iQ9 JeiwR1IozvWE3qQH4brhQ4e1TCVN23+njkjVkn1A5k3dzLbBVn95ta//dYcEIqxxWaEO 7W9W//UMnUhEL62BJbjc6WlB+sRTGhj5AdmazbNSSCpWi5sbVwgIYDvtYazhZZTd7yLr k+VA== X-Gm-Message-State: AC+VfDw/1VgUEhgVFS31yjmkzzc/Za7fFRJuWqnByjdKXZroVsry1Pgb 7abiPZ2FTiRyfuw5fd20Xxs= X-Google-Smtp-Source: ACHHUZ4QlfQRCCyEo0NT2cStZBCSFK0Rmz2GuDJaewi5+bnHnrGGKjaBld5zFyvEJolAPm298lLx3Q== X-Received: by 2002:a2e:9612:0:b0:2a8:ea26:607f with SMTP id v18-20020a2e9612000000b002a8ea26607fmr993418ljh.31.1683214388639; Thu, 04 May 2023 08:33:08 -0700 (PDT) Original-Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id j21-20020a2e8255000000b002ab0d1c9412sm5394081ljh.139.2023.05.04.08.32.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 May 2023 08:33:08 -0700 (PDT) Content-Language: en-US In-Reply-To: <87bkj1g10g.fsf@localhost> 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:261024 Archived-At: On 03/05/2023 17:30, Ihor Radchenko wrote: > Stefan Monnier writes: > >>> This looks interesting, if we replace all the requires in Org with >>> `my-require-with-shadow-check'. ... > Max, do you see any obvious downsides in Stefan's idea about consulting > `load-history' vs. `load-path'? First of all, I think, incremental builds are broken in Emacs. `org-assert-version' is just the most apparent manifestation. gcc supports generation of dependency files as a side effect of preprocessing for decades, see - (info "(make) Automatic-Prerequisites") https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html - https://gcc.gnu.org/news/dependencies.html Dependency Generation Improvements. 22 January 2001 - https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-MF The idea is that clean build does not require dependency map. For a rebuild, .d files are included into Makefile, so make is able to determine proper order of compilation. Perhaps a similar trick may be done in elisp by advicing e.g. `load'. Instead of dependency tracking Makefile in Emacs uses much more limited approach with the main-first target. That is why incremental build may easily result in mixed-version compilation. Imprinted Org version just detects such case. By the way, generated dependency map might help to properly reload a package update without restarting of Emacs. It seems, despite "make" in the bug title, it has been decided to dedicate this issue to plumbing of `org-assert-version'. Inspecting `load-history' might be tried, however such approach may cause other issues. I have heard that some users complain concerning Emacs startup time. Likely a hashmap will be required in addition to the `load-history' list to avoid performance degradation. I am unsure if the following idea have some benefits: check shadowing when `load-path' is modified, not for each file loaded from the newly added directory. I am unsure that path comparison is able to detect a problem when a user reloads Org after git pull and compiling new version. Files with new functions and macros are loaded from the same directory. In respect to incremental builds, `org-assert-version' is a disaster. Any update requires full recompiling. It is a reason why I always considered it as a kludge. Unfortunately I do not have a better idea. We need a tool that clearly informs users that they have issues with their configuration files, multiple versions of a package are available and it causes mixed version loading with inconsistent function definitions or, even worse, mixed version compiling with obsolete macro definitions. Emacs restart with fixed loading does not help in the latter case. Before introducing of `org-assert-version', errors were obscure: undefined functions or incompatible arguments (for internal functions). Unfortunately `org-assert-version' have caused another stream of complains. The issue is not limited to package.el or replacing built-in package. Various ways to load packages are used, so a couple of versions may appear in load-path even for non built-in package. The tool should detect version mismatch during loading, reloading, and compiling of an update. I think, both aspects must be addressed: - Improving dependency handling during incremental builds - Informing users about issues with loading of multi-file packages.