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: Fri, 5 May 2023 23:37:36 +0700 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> 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="29795"; 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: Ihor Radchenko , 62762@debbugs.gnu.org, bzg@gnu.org, dmitry@gutov.dev, Alan Mackenzie , Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 05 18:38:18 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 1puyRl-0007bF-PV for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 May 2023 18:38:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puyRX-0005kV-NY; Fri, 05 May 2023 12:38:03 -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 1puyRW-0005kA-J6 for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 12:38: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 1puyRW-0005yn-BL for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 12:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1puyRV-0005qG-RO for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 12:38: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: Fri, 05 May 2023 16:38: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.168330467122439 (code B ref 62762); Fri, 05 May 2023 16:38:01 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 5 May 2023 16:37:51 +0000 Original-Received: from localhost ([127.0.0.1]:57322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puyRK-0005pr-SL for submit@debbugs.gnu.org; Fri, 05 May 2023 12:37:51 -0400 Original-Received: from mail-lf1-f49.google.com ([209.85.167.49]:60497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puyRF-0005pY-Ah for 62762@debbugs.gnu.org; Fri, 05 May 2023 12:37:49 -0400 Original-Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-4efe8991bafso2338073e87.0 for <62762@debbugs.gnu.org>; Fri, 05 May 2023 09:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683304659; x=1685896659; 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=UqIVHTUYyUPP47KWJ7V3rC9RrvtbKgNIKxtsYmyYVkc=; b=jBWU1Li2qGvObnXBjHww8eq9gvf7PlJhcGbClSAO+C2a4rTSiYI9q0b8/olOXZqq78 k3aRQQQEIheaKqP2vD+wc/896GZn+YAyp4Y6/0q5tU283xcPGpIKn93NnnKKUXhuOKWE 8GHHzm+KuNGiLlySLzdPczPoWVDswFIv5V3Dk7Ze9M1t4utkNnJSsgY+ZVYqrpRFXIgG 7UZHq6FwvGrxEwW4r54qQN5YGZ0u6G0ttYMC7QARAgxGWlsrhopmeUP2JA2wiD2l/pPK AxuHi86I8XXfIA2vVunie1KZLBxzJULcZPDI5V5HwACeIpU3Kd0FrGUN+JbInpZ+ldSd 0ksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683304659; x=1685896659; 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=UqIVHTUYyUPP47KWJ7V3rC9RrvtbKgNIKxtsYmyYVkc=; b=C4r+6OQpls/GSnQbBl4YUgu17QX+zT2TBDiC8VE4ATcMLdn7ssa6jZtfwJnqcZUJjB x9hWXieznmV9HSZG0mYa7gRrGG4d26H6br//63EYyz1Us/EAcfK8c783qrmqeVtGJ5VU xwkmrRz63KPnlpYWtaHS6Dz7jD2x1+iLWAsiacbeMGmQAo54Rb4/3O2x8n1Hp+KKk5K6 z/yurJqXXOD8sn7+q9FPBxaexq2S8JKx4T4NEUCsAoF0HKj2Ekb+W7F56L8QHcHudBHV uPX275N1aOzGuyURgcGuJjEfZBeeMpB0jCz/CaY20v4wPHNasCdB4cQxfZrJ9CCpc2dt oFJQ== X-Gm-Message-State: AC+VfDyG+CKFEIbFW8O29Hf7CtmqrOne+awFsxK8MD3onnH8HXQ3iOcD EQ7gt1KNobNr4vAE8XEmlL4= X-Google-Smtp-Source: ACHHUZ5ZtGaSukUrh7sfLoeHUKQJveGzhBZ8Bwu2nTeQ0O/R+KaJIyWbdz0gtGvz5gqUW8Z7tN2i9w== X-Received: by 2002:ac2:4c32:0:b0:4f1:43f8:41f6 with SMTP id u18-20020ac24c32000000b004f143f841f6mr813199lfq.69.1683304659138; Fri, 05 May 2023 09:37:39 -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 n2-20020ac242c2000000b004eca2b1c5b4sm346705lfl.229.2023.05.05.09.37.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 09:37:38 -0700 (PDT) Content-Language: en-US In-Reply-To: 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:261119 Archived-At: On 05/05/2023 21:29, Stefan Monnier wrote: >> `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. It was not me who bring `load-prefer-newer' to this discussion. My point is: if timestamps were helpful to solve the issue with using of stale .elc files during incremental built after update then check based on .el content hashsum would do it even better. > E.g. the mixed-version problems that `org-assert-version` tries to > detect can happen without any `.elc` file in sight at all. Current variant `org-assert-version' can not work when Org update is loaded uncompiled, Certainly mixed version loading may happen purely with .el files. Mixed compilation issue (the topic of this bug) happens namely with .elc files. >> 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. If *.el files had higher priority than newer *.elc files than compiling result would be correct. An .elc file may become stale not due to change of its .el source, but due to changes in required files. The price is slower incremental builds. Initial clean build may use .elc files. This is applicable to Emacs builds, things may be more complicated when users build Org updates. > 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. I see 2 possible routes to avoid make + org-assert-version issues - to make incremental builds really reliable, rather than just "it generally works well" - improve `org-assert-version' Unfortunately committed code made `org-assert-version' less efficient. The function you suggested may solve some issues, but I am unsure if it can replace current variant of `org-assert-version' completely. I have no ideas how to make `org-assert-version' better. I had a hope that dependency generation may solve compiling issue, but I can not figure out what sort of circular dependencies is troublesome. I just must believe you and Eli. > [ I'm stopping here, I have to go. ] Certainly there is no hurry. For me priority is the following: Example of circular dependencies that may cause trouble during determining of compiling order (names of files or complete example, I hope it should not be longer that a dozen of lines). Whether I missed something and your function may handle loading files from updated directory.