From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Date: Fri, 05 May 2023 10:29:08 -0400 Message-ID: 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> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@gmail.com> <6070e598-7dee-1b7a-7f97-26a90618cb7a@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12061"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Ihor Radchenko , 62762@debbugs.gnu.org, bzg@gnu.org, dmitry@gutov.dev, Alan Mackenzie , Eli Zaretskii To: Max Nikulin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 05 16:30:21 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 1puwRw-0002vi-Rk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 May 2023 16:30:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puwRh-0000oW-RL; Fri, 05 May 2023 10:30: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 1puwRf-0000o5-Aa for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 10:30: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 1puwRf-0005iy-1P for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 10:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1puwRe-0008Jn-Si for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 10:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 May 2023 14:30: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.168329696031892 (code B ref 62762); Fri, 05 May 2023 14:30:02 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 5 May 2023 14:29:20 +0000 Original-Received: from localhost ([127.0.0.1]:57216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puwQx-0008IK-EE for submit@debbugs.gnu.org; Fri, 05 May 2023 10:29:19 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puwQv-0008I6-1S for 62762@debbugs.gnu.org; Fri, 05 May 2023 10:29:18 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B6FF380ADE; Fri, 5 May 2023 10:29:11 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1DE62802FA; Fri, 5 May 2023 10:29:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683296950; bh=DTEB3ZIP8pOOIRGAxyNqzKc7orjfM7klwVqG+MDKi2c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oX77/VyEn8FoOgndf0Pvdq8MvWr4mFa5voJH8xvcI2Rv2Vc6CGyHfaat8Sy0YGuqX x5eRWU1UI3wY6/llLRO8uk85zpnxHmUBOy9FzTANFp6c08uiXlCPLpOnVZeWasZeWy XIUtrr0mA+hO15R2lDZWqgHRvEhRH8SGcTEjT3b3loVjGFqtMyO6FVUbkgzhztZ9hN +LhUoe1krWbXg3l1Jhj+KGysuNiNsW+Tvv1IcYfM1XDFIy9qf0VoHIXoEprXF9nYGo AT9q/Wn5KzsV+mv8uK33DHFl9NBI1g0CmWEeC4K/RgzrmAn9tUMk4Ko1AyCTVmXhPR 2oHNWSkVcODxA== Original-Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C8BFA120515; Fri, 5 May 2023 10:29:09 -0400 (EDT) In-Reply-To: <6070e598-7dee-1b7a-7f97-26a90618cb7a@gmail.com> (Max Nikulin's message of "Fri, 5 May 2023 11:18:17 +0700") 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:261110 Archived-At: Hi Max, > `load-prefer-newer' is a kludge as well. I have to point out at this stage that I feel your answers aren't helping address the very concrete short term question at hand. Instead you're pointing to well known problems left and right that only bite in very specific corner cases and with no really clear solution. The problems `org-assert-version` is trying to fix happen a lot more often than those corner cases and are much easier to handle. > E.g. Python people migrated from comparison of timestamps to > inscribing of .py file hash into byte compiled .pyc files. Good for them. But that's unrelated to he problem at hand (and would only make a difference in cases that are a lot more hypothetical than the ones we're considering here). E.g. the mixed-version problems that `org-assert-version` tries to detect can happen without any `.elc` file in sight at all. Could we focus on the problem at hand, please? > By the way, `load-prefer-newer' make things even worse [...] (.el > files not changed, so they are older) No, if ".el files not changed, so they are older", then `load-prefer-newer` has no effect at all, so it can't make things worse. >>> `org-assert-version' is just the most apparent manifestation. >> AFAIK `org-assert-version` tries to solve a different problem. > Of course `org-assert-version' was introduced to solve another > problem, but it highlighted issues with dependency handling during > incremental builds. Yes, ELisp has lot of other problems. But can we move those discussions to other bug reports, otherwise I'm afraid we'll never get anywhere. >> Indeed, we recently introduced `org--inhibit-version-check` >> specifically so as not to use `org-assert-version` for Emacs's broken >> incremental builds (i.e. we decided we preferred that brokenness >> there). > `org--inhibit-version-check' is even uglier kludge that partially > deactivated `org-assert-version' Maybe so, but its addition is still the embodiment of people's judgment that for `git pull; make` in Emacs's sources, `org-assert-version` is worse than the problems it tries to address. > and just hides the issue with dependencies for incremental builds. No, it doesn't. >>> Perhaps a similar trick may be done in elisp by advicing e.g. `load'. > Another idea: while single file is compiled per emacs invocation > `load-history' may be compared before and after byte compilation. It's not really "another idea" (unless you meant `advicing` in a very narrow sense, but since we don't like Emacs to use advice within itself, it would be a non-starter). It's just one of the many ways to implement that same idea. >> I can already warn them that an important problem will be the >> presence of cyclic dependencies. > In the C and C++ world the solution for cyclic dependencies is forward > declarations. Some kind of such approach I see in Org as > well. lisp/org/ol.el and lisp/org/org-element.el are mutually > dependent. org-element.el requires 'ol, while the latter just declares > functions from 'org-element. > > When dependency files are generated, it is possible to create a report on > cyclic dependency and to disentangle them. As part of my janitorial work, I regularly have to try and disentangle circular dependencies. In my experience the hardest part is to convince the upstream maintainers to accept the churn, even though it brings no material improvement (and forces them to get used to the new code organization). So, yes, technical changes could help, but it would only go so far. [ I'm stopping here, I have to go. ] Stefan