Received: (at 62762) by debbugs.gnu.org; 24 Nov 2023 18:56:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 13:56:49 2023 Received: from localhost ([127.0.0.1]:37285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bM9-0007fM-BE for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:56:49 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r6bM6-0007f6-Gl for 62762 <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:56:47 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 03EBB5C0207; Fri, 24 Nov 2023 13:56:36 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 24 Nov 2023 13:56:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700852195; x=1700938595; bh=MWZTQ8bttlO5DzhgjzTyamBWIWcF+BtuE/Y YEwJPOuM=; b=uCX1MPN0kVDPHEogU0SjPbu0pWqqt8i+4OkoPDG5WxVO+vaeHi4 N5KZ97DUZa/Ej4eDqSenmf84i2Ffo4q9sl5QfQRxeKYF4495epsRjx0gWGGIRqVj VJVelgt60+Kwk/27YRSja6753BQe2ZguIADqnGuzAJVl8hREaU4lEF6vhd6lQxaC /T4D4AYXKH9eHfM9SpP1PvsgitF+cYZ6tnP8DmuDIUQux4fDPaTQGhsXaFl/vwoH xKD9yTW6JTD0s2Gi+VLRBZQXyYzgQKUOt3uDJMym1eWM+xRW1adxlZEVJbfhxT1x Kiy7efniPlbZvlJw02NtVoZIG24uYVS++Sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700852195; x=1700938595; bh=MWZTQ8bttlO5DzhgjzTyamBWIWcF+BtuE/Y YEwJPOuM=; b=w15SlSvMpn2VOOFzA8AbSKqQc5XcK4p4PA3OLoto7IKwTyU5rz2 7CepinwahHlWzRljmEiqOqmldXGSUpPSagpbvdnVTNBXFO0/cPrChrcgwaJfykL7 esFWH1RVXEHVZImZgidx4YO81puqBHF+8pp/wrsUzZ2xgeat3Mk0jtQbR8Ch2mbg jc6RdONiFSE0gn2LTjrPx0Z2DJ6WtNLkYtcsV9d5eElIX3blXy43BPbbHScjXeGp 5pmluO2sn3fpuZIcP8rbd1Sqopq9umF8V3xtchJbN8tlI4kRX18N86FUPSfXee7X ACP3hgliIe0ci4j0aWv+BJC7F6Med7hm1zw== X-ME-Sender: <xms:4_FgZVMA4CZrv8recjGYd0M_BB9GaLBQjNbgGSqB2618CWdoEp8zzQ> <xme:4_FgZX_RJFzubVzmU0te1yBW8hE0WMDlVViQ3_lU6XHcdlx8ZtIjCG0Q_WLcHYdSt QVPc9iH60DKAHSCQZA> X-ME-Received: <xmr:4_FgZUSlWYpxb0vXvNlXeCdBU037st0T6H-tOy_67IKSLFNnktcotPT7yZ7NfxIx3I11dw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:4_FgZRviOQrbv6F8KPL3Wn5Fr5vbtGZ6I9dqUDUV0-WZLkN1lEzMRA> <xmx:4_FgZddL8XLVAOx_D65DJYnj5q4KylySyZm49gYBMuC8FIsKq1CaKQ> <xmx:4_FgZd0Q-5ffeEvcSdmN-lxmT82iLX0ONidKnt0CpH9IMcEOnHoa5g> <xmx:4_FgZU5RUjBrrcfftr7TYFaNDASNYkNgJoDdpDmYp_xQxP63bCLBiw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 13:56:32 -0500 (EST) Message-ID: <162de3ab-cd7c-c7c2-ab9f-38dc57003b6e@HIDDEN> Date: Fri, 24 Nov 2023 20:56:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> <87sfcrt1ta.fsf@localhost> <83leihy18o.fsf@HIDDEN> <87fs8ptqe4.fsf@localhost> <4cd906ac-a500-86ac-6c62-d4c7f4ebb06c@HIDDEN> <83sf4vdlsi.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <83sf4vdlsi.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, monnier@HIDDEN, kyle@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 24/11/2023 20:54, Eli Zaretskii wrote: >> Date: Fri, 24 Nov 2023 19:43:53 +0200 >> Cc:monnier@HIDDEN,bzg@HIDDEN,62762 <at> debbugs.gnu.org, >> Kyle Meyer<kyle@HIDDEN> >> From: Dmitry Gutov<dmitry@HIDDEN> >> >> I still see the "Org version mismatch" error fairly often when >> rebuilding Emacs (after which I have to invoke 'touch lisp/org/...' >> again), or when trying to use org-mode in an already-built Emacs. All of >> that with the master branch. > That's because the version test was not removed, just suppressed in > the most frequent situations during the build. But when Org files > need to be actually loaded (e.g., to generate a manual out of some > foo.org source), the test will kick in and will abort the command. > > The only way to avoid that is to redesign and reimplement the solution > for version mismatch in Org macros. I thought the idea was to skip the version check at least when the Org version is built-in? That is, comes with Emacs as opposed to being installed from ELPA.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 24 Nov 2023 18:54:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 13:54:56 2023 Received: from localhost ([127.0.0.1]:37280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bKJ-0007c4-QZ for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:54:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1r6bKH-0007bs-FW for 62762 <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:54:54 -0500 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 <eliz@HIDDEN>) id 1r6bK6-00005h-EX; Fri, 24 Nov 2023 13:54:42 -0500 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=294tpyW5YtI+P/YCfUGQmD0BGbZkYyEEd3kTwNmgPmw=; b=S+B98WRFoKuZ sV6Mg4l01Or/bxvKXfEOQ99ZiYZ8uc90CeUju/zj47OByC9g+b+Ra1hpYG3M9dhrtxrKOQxQa1nx5 XHMkY+8ks6UZl3tWeNaYzjvGZE+y/piofIRKPdy+O8keFvPcDXxj5zFE9I4rCjSNBSj3h5gjQogNC dwL/mmJSW0gdpxVXIIklluBMlbt6kVab3Mc5hE2Di40gshbzm6GkFbB3d1SbtCgOs8fbqlmArOsy5 LIxeJNuGQOLFOYYmZIyn0NAd5ODjb7lUbhxBFJOh4iuBm0QczDUhkx4DYmWDB48bqrWW/Can5DQ5Y 0gjVDJnMnZDMSEoCBmmdZg==; Date: Fri, 24 Nov 2023 20:54:37 +0200 Message-Id: <83sf4vdlsi.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <4cd906ac-a500-86ac-6c62-d4c7f4ebb06c@HIDDEN> (message from Dmitry Gutov on Fri, 24 Nov 2023 19:43:53 +0200) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> <87sfcrt1ta.fsf@localhost> <83leihy18o.fsf@HIDDEN> <87fs8ptqe4.fsf@localhost> <4cd906ac-a500-86ac-6c62-d4c7f4ebb06c@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, monnier@HIDDEN, kyle@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 24 Nov 2023 19:43:53 +0200 > Cc: monnier@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org, > Kyle Meyer <kyle@HIDDEN> > From: Dmitry Gutov <dmitry@HIDDEN> > > I still see the "Org version mismatch" error fairly often when > rebuilding Emacs (after which I have to invoke 'touch lisp/org/...' > again), or when trying to use org-mode in an already-built Emacs. All of > that with the master branch. That's because the version test was not removed, just suppressed in the most frequent situations during the build. But when Org files need to be actually loaded (e.g., to generate a manual out of some foo.org source), the test will kick in and will abort the command. The only way to avoid that is to redesign and reimplement the solution for version mismatch in Org macros.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 24 Nov 2023 17:44:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 12:44:13 2023 Received: from localhost ([127.0.0.1]:37203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6aDt-0005dE-0I for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 12:44:13 -0500 Received: from new2-smtp.messagingengine.com ([66.111.4.224]:44391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r6aDn-0005cx-Ko for 62762 <at> debbugs.gnu.org; Fri, 24 Nov 2023 12:44:11 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id DE72F5819FC; Fri, 24 Nov 2023 12:43:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 24 Nov 2023 12:43:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700847837; x=1700855037; bh=QoGSsJtp6orPZ6RaD/q0kf1xUyQjcuJmdwz zZCmBIbs=; b=AiEZ1sgnmRkN1U3Q5xRdlMZmGUefi268GuJyqF20wsMJutTHAbJ hedolr0iTLoXNNZdlvqXQU/wcS1hwPxAHBn3vI2j1VV1xqECXZLH+gEtsrU109af seuWYoAErR/MCkQP6Eu3iGRox/sOZg2oafASM9K+EICbe0ZnFFal9vwls0C8dykN wmpqIzU/IwZVhEquZRI3KsRz1hs+6wsayufI1kVCK5/TQy7/4G0/lXwSBvHUAy8x o9+/F2mmdXHuRW/7ny+EYt1JFjYqArbb1VCvt5A3HKDgA+lqb//QL/WEtzfZFQze ONjvUJCcI6p/9xN7jtyTc+rlq+tV6pQOJrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700847837; x=1700855037; bh=QoGSsJtp6orPZ6RaD/q0kf1xUyQjcuJmdwz zZCmBIbs=; b=sL7Z3XdAEw9VR6MizaMwAHtlT/5AM0zu5aPXI1zPdStLdyzS6df /h/px58U6U01larc79pRTicbeFbcJRmBQ200yjFSFArJ9BHEyga4hZESLN4vYH2w uAN6cu727msaRCchzHSMhQefRq1caAgHLee3gL0yRK3oJc1Vg+kz6hLeuOionY7l IfnfN3b53lFitUKLWhd9MaIbp5fCK/NiAoIB7fcaQ2wCYC9830TGXj1Te1jQdRRx /mnyj5wrzamQS7Gu+jdufvWpOYZutubxpfU+JOTw9rBnn3xJ/gZMa9uideTe5QLZ NzyvbERuWnVO4zqGVm2BQmvFCPT82giKdpQ== X-ME-Sender: <xms:3eBgZdjOE4XwGM0NriczijHoLlmChu1RRLilza6cF87SCvbX2VNe9A> <xme:3eBgZSA-W7wb8q9Nzhuo2AbC_Yn4yQKsN4-sF0q8yQ1wwEoRvmHSj25dWd5XpD8V3 rWQUZL4cTgseKg-K-g> X-ME-Received: <xmr:3eBgZdGLiinjurtWFvzhTkDdm_K9NZCw0lR-6qmVHm_NCqqTjIZ4kywzHQvjcw-fr4w3gw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfggedvkedqudduucdlfedttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgseht jeertddtfeejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesgh huthhovhdruggvvheqnecuggftrfgrthhtvghrnhephfeutdekveeggeetteekfeejffeg udduudfhueevleeftdffffeggeeivddvjeelnecuffhomhgrihhnpehgnhhurdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihht rhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:3eBgZSS6KpE1KjSpGAGTHnQQVT6d88DEbev5IbQWkHYrooHbm49zrw> <xmx:3eBgZaxd4T_ULKecqCrd2M0n0fn7gA5wVnrcRDMxKdPpXndNCOGrdg> <xmx:3eBgZY4GlLDoE6qQRBx47uA46aAwkuM-iJXVjlD6usej0ch3WTXIDA> <xmx:3eBgZUsC2aoGb_Y8FdWUykqQFStVRWShfkmqqpv27GPNc7wv_xM2FA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 12:43:55 -0500 (EST) Message-ID: <4cd906ac-a500-86ac-6c62-d4c7f4ebb06c@HIDDEN> Date: Fri, 24 Nov 2023 19:43:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> <87sfcrt1ta.fsf@localhost> <83leihy18o.fsf@HIDDEN> <87fs8ptqe4.fsf@localhost> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87fs8ptqe4.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, Kyle Meyer <kyle@HIDDEN>, 62762 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 24/04/2023 15:29, Ihor Radchenko wrote: > Eli Zaretskii<eliz@HIDDEN> writes: > >>> Let me know when you install the change on Emacs side. >> Done. > Thanks! > Backported:https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8eb209984 > Kyle, let me know if I did anything wrong. Just to give an update on the problem: I still see the "Org version mismatch" error fairly often when rebuilding Emacs (after which I have to invoke 'touch lisp/org/...' again), or when trying to use org-mode in an already-built Emacs. All of that with the master branch.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 4 Jul 2023 12:20:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 04 08:20:57 2023
Received: from localhost ([127.0.0.1]:35137 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qGf1d-0001ze-0W
for submit <at> debbugs.gnu.org; Tue, 04 Jul 2023 08:20:57 -0400
Received: from mout01.posteo.de ([185.67.36.65]:40651)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qGf1X-0001zK-VG
for 62762 <at> debbugs.gnu.org; Tue, 04 Jul 2023 08:20:55 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 3962B24002B
for <62762 <at> debbugs.gnu.org>; Tue, 4 Jul 2023 14:20:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1688473246; bh=iPfuTi+q4obubca9Lhfocsn3SrJYeC/hKaiGRkmw+34=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:
Content-Transfer-Encoding:From;
b=jVIxvWa8CYEOHJeFaVFL8q+Km3OFGZWnyiggIUtT2euaFx3tj6a/JeuJ2WtFMPXkE
BDMKPu/SVRUGEMe0AUrHxs6scpocga0rTh6S/75Uf2ySmsU4x4ZvQDziiEKiQcpxAD
1pOmCqY1Z382N4r7WFMaD1d9u1lMJkB9/lIC9vV3L4ItaYAO1BEfysKY1iUkeMweni
YDTKkk/9IQ7iGAV4OqnFO9Hqzw+bXghT1fyAirrImRf3PZVLKZAXJKbNzNPFJP8CUC
evJZTURlWvi8TovqrOh4CDQGQnP3PC07o2uED8sjr12Ib2LrqT5wYZFvOZFwNWkPPB
YacuEEhL6UGaA==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4QwMMF5gf8z9rxL;
Tue, 4 Jul 2023 14:20:41 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <8d3db18e-301b-586e-a90c-4d968df4b56a@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
<03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN>
<875y93kujy.fsf@localhost>
<2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN>
<871qi2mlnc.fsf@localhost>
<0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN>
<87leg5i30y.fsf@localhost>
<8d3db18e-301b-586e-a90c-4d968df4b56a@HIDDEN>
Date: Tue, 04 Jul 2023 12:20:25 +0000
Message-ID: <87cz17rhpy.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Max Nikulin <manikulin@HIDDEN> writes:
>> Do you know how to do it? Our previous reproducers involved M-x
>> package-install, but I am not sure how to test it without ELPA release.
>
> I have not tried yet, but I hope, preparing a tar file and using=20
> `package-install-file' should behave in the same way as installing from=20
> ELPA. Some spacemacs users believe they have noticed some difference,=20
> but I am not convinced.
I tried this and indeed it revealed issues...
With
(defmacro org-require-with-shadowcheck (feature)
"Load FEATURE making sure that it is loaded using current `load-path'.
When FEATURE is not yet loaded, act like `require' does. When FEATURE
is loaded, but not consistent with the current value of `load-path',
re-load it."
`(eval-and-compile
(if (not (featurep ,feature)) (require ,feature)
(let ((file (locate-library (symbol-name ,feature))))
(unless (equal (feature-file ,feature) file)
;; The feature is already provided, but from some other file
;; than expected. Presumably because `load-path` has been
;; changed since the file was loaded. This is likely a sign
;; that we're loading a mix of files from different versions.
;; That can spell trouble.
(load file nil t t))))))
using https://git.sr.ht/~yantar92/org-mode/tree/feature/shadowcheck
1. emacs-30 -Q
2. M-x org-version
3. M-x package-install-file <RET> /path/to/org/lisp
I am getting
ob-C.el:40:2: Error: Eager macro-expansion failure: (error "Eager macro-exp=
ansion skipped due to cycle:
=E2=80=A6 =3D> (load \"org-element.el\") =3D> (macroexpand-all (org-requi=
re-with-shadowcheck 'org =E2=80=A6)) =3D> (macroexpand (org-require-with-sh=
adowcheck =E2=80=A6)) =3D> (load \"org.el\") =3D> (load \"org-element.el\")=
")
which is rather curious since org.el is not supposed to load
org-element.el
I feel that I am missing something obvious.
--=20
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 16:11:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 12:11:49 2023
Received: from localhost ([127.0.0.1]:49425 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qEBID-0004dH-E4
for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 12:11:49 -0400
Received: from mail-lj1-f176.google.com ([209.85.208.176]:54361)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1qEBIB-0004d4-Tu
for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 12:11:48 -0400
Received: by mail-lj1-f176.google.com with SMTP id
38308e7fff4ca-2b69a48368fso45959651fa.0
for <62762 <at> debbugs.gnu.org>; Tue, 27 Jun 2023 09:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1687882302; x=1690474302;
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=EIntMNUvBe7swpawG6gshCL3XrTueZSoHrzII6oHI8g=;
b=p+/+c1tA4Jvcv74YjY/1kbtHBQ3GXmQt23A5FrJE6VwIViTAlgEREdl13gW1jR6zr5
BiWbX1kV6S6FTuRaojtoAsq3pQ5EC810f5BwdYlkuIrwwBwbHVPKMMbBcTrwi76z5FSj
5kpqHDgiAc6K29saijeHJl1o77XQzwwOCcwx9RTjVtA3jKnL8V53Jtexf9O7WcC8uYK3
h1BaVM9hpd3dl6Vf43HX/eg8+IXD+LBvsOhnCkBYwsx8dVDmwsJYfWBQW3R7f4TGfeC8
L6NsLKrbeAiJYhr0eetxMiCcc8mH6Ra1pRS+7+CfSToLpviCG+msVMTvOebur3qcp3fV
avrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1687882302; x=1690474302;
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=EIntMNUvBe7swpawG6gshCL3XrTueZSoHrzII6oHI8g=;
b=V0LyqkWu6ptvfGq2dYiihRQP5qCQUT291iJURag4BA3fiPl9zHY66qhmzmv0Eo2/fA
YLMv6hsuaOk3wO69gv1jjhsfP0fLJhu6UXYSvaXiW4T9LFtUAnAJCZpGl+AwyX0F49lI
A52Xii2taZyehNboAkkAOObhBwpJlAz0guG3ZMwZFwcUPIX5yzxf6Q+zqpPcyVzLELWT
DttRpy/Gbiy+eA4AWc6WQjWy+8Hc4VPOk0Ch0T1+C3276IZb3n1qtxsFum1DCpnIfmew
DwDDEbesyeu04zOAQsu7Ul1mYShqaiqOa6784kljN6w5gGTPZjmhURMwDeD82ZU+sNae
14RA==
X-Gm-Message-State: AC+VfDzLBBaPhKIB8s3H4Bm4raP2CSR4Cy972EMvaAd4p57+1qFVJl6r
dHvlxljcQF9A1mo/rYL9UMo=
X-Google-Smtp-Source: ACHHUZ7oCSwEbuMARpUFRU2zRLkIYs2+f18MvSmC6rfwmkzlBOwKqsRhKbmm7ZVx5SrXpDFnF0whYQ==
X-Received: by 2002:a2e:b049:0:b0:2b6:a2dc:7681 with SMTP id
d9-20020a2eb049000000b002b6a2dc7681mr4421576ljl.6.1687882301577;
Tue, 27 Jun 2023 09:11:41 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
g12-20020a2eb0cc000000b002ad8174d025sm246630ljl.122.2023.06.27.09.11.39
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 27 Jun 2023 09:11:41 -0700 (PDT)
Message-ID: <8d3db18e-301b-586e-a90c-4d968df4b56a@HIDDEN>
Date: Tue, 27 Jun 2023 23:11:39 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
Content-Language: en-US
To: Ihor Radchenko <yantar92@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
<03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost>
<2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost>
<0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <87leg5i30y.fsf@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 27/06/2023 17:59,
Ihor Radchenko wrote: > Max Nikulin writes:
>> On 23/06/2023 19:02, Ihor Radchenko wrote: >>> I do not think that we
should throw and error. `org-reload' approach >>> should hopefully solve the
problem with mixed versions. >> >> Have you tested compilation with Org
already loaded to Emacs [...]
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.208.176 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.208.176 listed in wl.mailspike.net]
-1.1 NICE_REPLY_A Looks like a legit reply (A)
X-Debbugs-Envelope-To: 62762
Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 27/06/2023 17:59, Ihor Radchenko wrote: > Max Nikulin writes:
>> On 23/06/2023 19:02, Ihor Radchenko wrote: >>> I do not think that we
should throw and error. `org-reload' approach >>> should hopefully solve the
problem with mixed versions. >> >> Have you tested compilation with Org already
loaded to Emacs [...]
Content analysis details: (1.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.208.176 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.208.176 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.1 NICE_REPLY_A Looks like a legit reply (A)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
On 27/06/2023 17:59, Ihor Radchenko wrote:
> Max Nikulin writes:
>> On 23/06/2023 19:02, Ihor Radchenko wrote:
>>> I do not think that we should throw and error. `org-reload' approach
>>> should hopefully solve the problem with mixed versions.
>>
>> Have you tested compilation with Org already loaded to Emacs <= 28?
>
> Do you know how to do it? Our previous reproducers involved M-x
> package-install, but I am not sure how to test it without ELPA release.
I have not tried yet, but I hope, preparing a tar file and using
`package-install-file' should behave in the same way as installing from
ELPA. Some spacemacs users believe they have noticed some difference,
but I am not convinced.
> You are right. I will think how to approach this.
> I am considering:
> 1. Move most the warning to dedicated manual section.
> 2. Display additional short warning at the bottom.
>
> I am now leaning towards (1).
Since it will be only in new version of the manual, a URL with online
manual should be provided. Using `info' may give old version with no
added section. Perhaps the FAQ entry should be revised as well.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 12:51:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 08:51:59 2023 Received: from localhost ([127.0.0.1]:47855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE8Ap-0004oJ-9u for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:51:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qE8Al-0004o4-Bw for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:51:57 -0400 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 <eliz@HIDDEN>) id 1qE8Ae-00041J-J5; Tue, 27 Jun 2023 08:51:48 -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=l8M+hs2DnOozQSiO8kN1Ny9k/6MIWi18NC94Cep7i6E=; b=SUJQ3ZrZRAZz AFNYv52gt3AW46pSgpPXXegjn5+XOoR5gKBVs//EYDpGgnyfBAqe4rWWzB1lg9JWf9YonU5SEQ5FQ nXHaq2jwbqaxNYavc2B4DPX9wG+brKitbmSsI90nBlDFBgHlPIawa3sBpbNsd5cW91vuU+HmC1DvD gxOKNPQ4/PRI8Og5DgQp2PygEQsa+f6NHXkoKU+hFawG/x7TNZ65PiAMCKus1bjr3HFhZTsdqkkE+ 2Kd3n7Nqa2R9DxTBeDMvuXPD/eEp2xI1suG9fUaVJkO/NQ2YmePKBFt5JZnPelkWlBwU7z9Z6yEqD K4uI2Gcqz96CNu6LoYy+GA==; 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 <eliz@HIDDEN>) id 1qE8AM-0004gY-Hc; Tue, 27 Jun 2023 08:51:41 -0400 Date: Tue, 27 Jun 2023 15:51:51 +0300 Message-Id: <834jmtvziw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87cz1hay0m.fsf@localhost> (message from Ihor Radchenko on Tue, 27 Jun 2023 12:30:01 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost> <83a5wlw2ul.fsf@HIDDEN> <87leg5az0a.fsf@localhost> <837crpw1c1.fsf@HIDDEN> <87cz1hay0m.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN, manikulin@HIDDEN, kyle@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: manikulin@HIDDEN, monnier@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN, Kyle Meyer > <kyle@HIDDEN>, Bastien <bzg@HIDDEN> > Date: Tue, 27 Jun 2023 12:30:01 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> This is aiming for Org's bugfix branch (as a critical fix). > >> AFAIK, Org bugfix releases were going into release branch. > >> > >> At the same time, this change is not aiming at Org distributed within > >> Emacs tree. The whole issue is with ELPA version of Org. > > > > The above two paragraphs contradict each other, AFAIU. If a change is > > installed on the release branch of the Emacs Git repository, it will > > be included in the release tarball, and thus in the Emacs source tree. > > > > OTOH, if this is not about the Emacs Git repository, then why did you > > say you were asking Emacs developers these questions? > > > > I guess I'm missing something here. > > Normally, every Org release is synchronized with Emacs upstream (master). > During the Emacs release, we have done the same for Emacs emacs-29 > branch (Org 9.6.6 is included in emacs-29; see > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/org/org.el?h=emacs-29#n12). > > However, during the Emacs release process, if significant changes have > to be done on Org side, we may consider not syncing the Emacs release > branch and Org bugfix. See > https://orgmode.org/worg/org-maintenance.html#org-version-emacs > > But definition of "significant" is subjective. So, I wanted to clarify > with you (Emacs dev). I'm not sure I understood the above, but just to be clear: the emacs-29 release branch was not supposed to have any of the changes meant to prevent aborting the build due to Org version mismatch. I now see that the org--inhibit-version-check change did somehow get installed on emacs-29, and I think it's unfortunate and was never discussed. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#53 and again in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#65 I clearly said that the change was installed only on master. I think the fact that this got backported to emacs-29 was unintentional.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 12:25:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 08:25:18 2023 Received: from localhost ([127.0.0.1]:47838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE7l0-00043z-1E for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:25:18 -0400 Received: from mout01.posteo.de ([185.67.36.65]:60883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qE7kv-00043j-2N for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:25:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 39B3E240029 for <62762 <at> debbugs.gnu.org>; Tue, 27 Jun 2023 14:25:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1687868707; bh=ZE5fvJPPA7AVELGPGjfUrk0iu554eQQ3dVT4dYU2ILY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ayTr7ycC6T2gAtdFUy7i/EHZxWGrjgL4Nv/oNMS6Xic2jm6InlnP0PchbFM1Vuu+r tWqTUboSeNneYo5eosA4QTeLZewyt9DQ21tI3P1zgPdxi0xa0qjzbmqwD5ifXvrjPT NUmXXIBrRRbg7B6PsTWcckDqRKEH4Rk6shrRis78dczEI5lFuLBDqxnEISoIn9C/f1 LI46IDgiDnaur4RVCHNWR8rQKQYxKIioz5lOteLETPZomcCf9isXTFJshMpeS5FMUS AHLK90R87Ql4RwBSLQ3/8L5tsQAPmOuPwvrgL7zdunwZrCWK9pMFhATKqnkYfee+sq O/vU5CzYVJFoA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qr3nY0TRsz9rxF; Tue, 27 Jun 2023 14:25:04 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <837crpw1c1.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost> <83a5wlw2ul.fsf@HIDDEN> <87leg5az0a.fsf@localhost> <837crpw1c1.fsf@HIDDEN> Date: Tue, 27 Jun 2023 12:30:01 +0000 Message-ID: <87cz1hay0m.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, Bastien <bzg@HIDDEN>, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN, manikulin@HIDDEN, Kyle Meyer <kyle@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> This is aiming for Org's bugfix branch (as a critical fix). >> AFAIK, Org bugfix releases were going into release branch. >> >> At the same time, this change is not aiming at Org distributed within >> Emacs tree. The whole issue is with ELPA version of Org. > > The above two paragraphs contradict each other, AFAIU. If a change is > installed on the release branch of the Emacs Git repository, it will > be included in the release tarball, and thus in the Emacs source tree. > > OTOH, if this is not about the Emacs Git repository, then why did you > say you were asking Emacs developers these questions? > > I guess I'm missing something here. Normally, every Org release is synchronized with Emacs upstream (master). During the Emacs release, we have done the same for Emacs emacs-29 branch (Org 9.6.6 is included in emacs-29; see https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/org/org.el?h=emacs-29#n12). However, during the Emacs release process, if significant changes have to be done on Org side, we may consider not syncing the Emacs release branch and Org bugfix. See https://orgmode.org/worg/org-maintenance.html#org-version-emacs But definition of "significant" is subjective. So, I wanted to clarify with you (Emacs dev). CCing Kyle Meyer, in case if I misunderstand something. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 12:12:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 08:12:39 2023 Received: from localhost ([127.0.0.1]:47824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE7Yl-0003ij-4s for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:12:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qE7Yi-0003iR-MY for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:12:37 -0400 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 <eliz@HIDDEN>) id 1qE7Yb-00023t-4A; Tue, 27 Jun 2023 08:12:29 -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=FKOH/3FBH5Ukbuzn6Ieimpa/rm4wTI/SyG9fCzLq4gY=; b=dUy4bGNCTM3L /NmF8OEbDigQzkHq4XURsAuEvTGgwwFL/MbnzoU3edsv97y/z3ghCxNbZIJ9s/QD10Tv/cV2Ht8gd j85QIHHNBlmjglF9OTtqD1O88WD5nzDCwainjXchsiWjphUI5GMuadvg36WWSclE4MaRh3jgiAaQz NggHpM00VNEcaFWo4wsDW4sJduEXf35jHHLV16gqtX1R8iGVYMdxfyD9dkR3061eabQhSLrn11BCW b8MR1q9dx2tpIb4J7E6ssYgmcAMZ6UEI9756BM0CnylYdfJ9Ky049gQuNKSzpFovsHwG9zB3Pg45B 03f2MTNcWXn97bVGkSen9w==; 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 <eliz@HIDDEN>) id 1qE7YW-00029E-3N; Tue, 27 Jun 2023 08:12:28 -0400 Date: Tue, 27 Jun 2023 15:12:46 +0300 Message-Id: <837crpw1c1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87leg5az0a.fsf@localhost> (message from Ihor Radchenko on Tue, 27 Jun 2023 12:08:37 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost> <83a5wlw2ul.fsf@HIDDEN> <87leg5az0a.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN, manikulin@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: manikulin@HIDDEN, monnier@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > Date: Tue, 27 Jun 2023 12:08:37 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Installing is not the concern. My concern is introducing major changes > >> right ahead for the release. My question was aimed at the Emacs devs > >> here. > > > > I was not aware that this discussion is pertinent to the release > > branch. Is it? I thought any changes in this matter are for master. > > This is aiming for Org's bugfix branch (as a critical fix). > AFAIK, Org bugfix releases were going into release branch. > > At the same time, this change is not aiming at Org distributed within > Emacs tree. The whole issue is with ELPA version of Org. The above two paragraphs contradict each other, AFAIU. If a change is installed on the release branch of the Emacs Git repository, it will be included in the release tarball, and thus in the Emacs source tree. OTOH, if this is not about the Emacs Git repository, then why did you say you were asking Emacs developers these questions? I guess I'm missing something here. > In any case, if Emacs release is coming really soon, I can just hold on > until Emacs is released. As long as this code will be in Emacs on the master branch, you don't need to wait for the release (which is done from the release branch).
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 12:03:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 08:03:51 2023 Received: from localhost ([127.0.0.1]:47808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE7QF-0003Uq-HI for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:03:51 -0400 Received: from mout02.posteo.de ([185.67.36.66]:48113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qE7QC-0003Ud-Kx for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 08:03:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D6A23240105 for <62762 <at> debbugs.gnu.org>; Tue, 27 Jun 2023 14:03:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1687867422; bh=C6o4Kj13PVAtFB5A0+lg9s23BYDt8GCfdOUBhLQtaWo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Kt6tzGVWvjbflMVV8g2lrNMTE56+h1UganOuv47BIwvd8WzDHQJKIt6e8x1g8paaT sRVQ59teoihDwnlg0uiHupa4TIE40UTqRZxcUDMHpvculPonhh0qcdrDyZwixvrL89 30viYlxKSrvKDUQFbAvCdXHY+pUmWvVJaM89D0elU1w9Lnkpzx71QcH4BluKMXtSZA VkXOLO59qWSdo8/FIxvlmHtrfyBSGu+FC5IpM1DtZLGlCFsjY383//s+Php5ZEWV71 vct50ur+8MXZO/ZjhlnVuKpbUYwD0PZBwyus+UXTYF3SXsjVyLYlEzFJJkhty5QevN dRiUQf/UytTww== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qr3Js3Klmz6tsf; Tue, 27 Jun 2023 14:03:41 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83a5wlw2ul.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost> <83a5wlw2ul.fsf@HIDDEN> Date: Tue, 27 Jun 2023 12:08:37 +0000 Message-ID: <87leg5az0a.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN, manikulin@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> Installing is not the concern. My concern is introducing major changes >> right ahead for the release. My question was aimed at the Emacs devs >> here. > > I was not aware that this discussion is pertinent to the release > branch. Is it? I thought any changes in this matter are for master. This is aiming for Org's bugfix branch (as a critical fix). AFAIK, Org bugfix releases were going into release branch. At the same time, this change is not aiming at Org distributed within Emacs tree. The whole issue is with ELPA version of Org. In any case, if Emacs release is coming really soon, I can just hold on until Emacs is released. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 11:39:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 07:39:54 2023 Received: from localhost ([127.0.0.1]:47786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE734-0002pE-JC for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 07:39:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qE732-0002p0-Jx for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 07:39:53 -0400 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 <eliz@HIDDEN>) id 1qE72v-0001tI-9J; Tue, 27 Jun 2023 07:39:45 -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=1yr3U5uybGHNJQD5UzG2CEvWnhgrzIHFGzuCxWAeCfI=; b=OO6/btNtqR+3 3/w/BHCVBnz03hm+4p7AKRw513qqKuhqeKCjOCmZYLqo8ARDQsfmzq4toslZWVl1SaLWbgRrdIN5A txZ3hsUt2+dDtkGnNH7FYv7revpOgj0uBFPCSSQ0usY2XJxAWImP4ILjmQ7+mW2WnMcThY67Hrnlf 2PAarGk8Uh39gzujrP7qAsd3XNn5dk08NjfsdHUz598QD/DRmzrc37gAMtL4vh+Q59LhiGIytOO1a 6UwcJN05OWMVGcdbeUyVZoB2SJ9kfE6yjgPBOjhfE/5ILXQWpqVLp1alLC4J3Qn3SswXIEgAJzAfA FRbLmOc+Hw2kql1U59W76A==; 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 <eliz@HIDDEN>) id 1qE72q-0001Ej-5Z; Tue, 27 Jun 2023 07:39:44 -0400 Date: Tue, 27 Jun 2023 14:40:02 +0300 Message-Id: <83a5wlw2ul.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87leg5i30y.fsf@localhost> (message from Ihor Radchenko on Tue, 27 Jun 2023 10:59:57 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> <87leg5i30y.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN, manikulin@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, Alan Mackenzie > <acm@HIDDEN> > Date: Tue, 27 Jun 2023 10:59:57 +0000 > > > My impression is that the most wide spread case is installing the Org > > ELPA package should just work in Emacs-29. I am unsure concerning > > precise scenario for spacemacs. I have not idea if shadowing by > > correctly compiled Org is a frequent issue. Are there other cases > > affecting significant number of users and what is behavior for them? > > Installing is not the concern. My concern is introducing major changes > right ahead for the release. My question was aimed at the Emacs devs > here. I was not aware that this discussion is pertinent to the release branch. Is it? I thought any changes in this matter are for master.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 27 Jun 2023 10:55:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 27 06:55:11 2023 Received: from localhost ([127.0.0.1]:47731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qE6Lm-0007fl-ON for submit <at> debbugs.gnu.org; Tue, 27 Jun 2023 06:55:11 -0400 Received: from mout02.posteo.de ([185.67.36.66]:46551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qE6Lk-0007fR-5b for 62762 <at> debbugs.gnu.org; Tue, 27 Jun 2023 06:55:09 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9F34E240104 for <62762 <at> debbugs.gnu.org>; Tue, 27 Jun 2023 12:55:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1687863302; bh=828KHW9oI5Y8MILk/teyiA2+9PQbtCUs4Bylhf2jREI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ecegc3/PZfGq3qlyNtbLEo3n+pjbL6+de/x5xYQZSjU0gGyu9pOLfTGfXA9qRK52M 5EEuBQy4JUwy6vnzKOkODg/DBf13gta2pokVB7gRl1jjyPv+LcGgppfFvxyp4D/q/m /QyscxchAojvfXnl9eaX1DL439NyXObaOhgIMzWcCRxC84fgmS9JU9G46lY+F5iYKy COojmjqGYC29/weBwATB1Y340araQemrSRsUzbkcxZa2t3FzCRTWHAYngCfWeHQiOw BdElPh2egGbZf+PT1eUhaYqpG01R0N+mq7U8qq9+8/CY1lenxdnnBsX0unGuWkd2Tj SZyO4P+zWcoHw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qr1nd1TgWz9rxN; Tue, 27 Jun 2023 12:55:00 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost> <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN> Date: Tue, 27 Jun 2023 10:59:57 +0000 Message-ID: <87leg5i30y.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Max Nikulin <manikulin@HIDDEN> writes: > On 23/06/2023 19:02, Ihor Radchenko wrote: >> 1. Use `org-reload' instead of load-dir test. > > Just a reminder: directory test may catch the case with shadowing by Ort > that is not compiled. Version comparison is unable to detect it. Yeah, you are right. We may need to combine both the approaches with shadow require and version check. I will look further into this. >> I do not think that we should throw and error. `org-reload' approach >> should hopefully solve the problem with mixed versions. > > Have you tested compilation with Org already loaded to Emacs <= 28? Do you know how to do it? Our previous reproducers involved M-x package-install, but I am not sure how to test it without ELPA release. >> P.S. I am not sure how to approach this patch in a view of the Emacs >> release process. > Are there other consequences of your changes for incremental rebuilds in > Emacs source tree besides converting error to warning? There are no consequences at all. The whole check is completely bypassed in Emacs tree. Even the warning is suppressed. See `org--inhibit-version-check'. > My impression is that the most wide spread case is installing the Org > ELPA package should just work in Emacs-29. I am unsure concerning > precise scenario for spacemacs. I have not idea if shadowing by > correctly compiled Org is a frequent issue. Are there other cases > affecting significant number of users and what is behavior for them? Installing is not the concern. My concern is introducing major changes right ahead for the release. My question was aimed at the Emacs devs here. > Current warning is so long that it may confuse users who sees only its > final part. You are right. I will think how to approach this. I am considering: 1. Move most the warning to dedicated manual section. 2. Display additional short warning at the bottom. I am now leaning towards (1). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 25 Jun 2023 14:37:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 25 10:37:20 2023
Received: from localhost ([127.0.0.1]:43218 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qDQrg-00025H-GT
for submit <at> debbugs.gnu.org; Sun, 25 Jun 2023 10:37:20 -0400
Received: from mail-lf1-f45.google.com ([209.85.167.45]:60900)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1qDQrb-000251-RX
for 62762 <at> debbugs.gnu.org; Sun, 25 Jun 2023 10:37:18 -0400
Received: by mail-lf1-f45.google.com with SMTP id
2adb3069b0e04-4f8775126d3so2945422e87.1
for <62762 <at> debbugs.gnu.org>; Sun, 25 Jun 2023 07:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1687703830; x=1690295830;
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=oq1LZMPdV6uMjiIWVDXCbpK9ngEs5AyXkPiCzqyccpw=;
b=oE0PsfVS7f5MbdYdcp69DlNQWBghIz2OusbkeGVsgg4Emh0Q3OgjB1M8qO/seXoQN0
CfGb1EJ1JfC9/xTAXZpIj+Sf335eGztbjGPKRkh5eeK5oiBIwOVO3R8tWxEyhBOZsuSH
+S3nxoRhk1b2y/APVMPEvlZraXjcCMdIorr3BADdWjaoqnPmEH7FvKovKEhWfgx7wyqp
ZjR4n99xxhd3UNuCZw2faDXSoPL1ME9FdLmnDR+B/kaQYK2JrVxqLc5US9sVS/B1tN97
v5wColC0VtyVUqsMB83pKsye/mf0jxUgaolZU261s0GhoD2ZrnHgmAuhVTFyKFhU4KXh
7GWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1687703830; x=1690295830;
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=oq1LZMPdV6uMjiIWVDXCbpK9ngEs5AyXkPiCzqyccpw=;
b=C49osddAj/czalG/39g7tzwprUpX81+8fv90U8M3WsruCUbkR2bcv4DjtT1FFr16BK
0qWy0HFHkV9GU7MhwVHSniqbL10Lw5LyU7ZrNFtW5Y5SSIEchiL969vjX/BBFjsX75C9
u3E5g16J+IMzO6LNXsRsZ7eubeIILTFAjgU+jyZ4rlygqaukQhjqMQodkMxgW821e/NH
z6Rn4C+qQvDb3X7vjtOZptzjtwpiEy8X8MNH4nYl+TaJ6Kc/osYbRnkLJsfiQTm0cEpt
faIspbf1Oo4Hd3xKMQjiqtiZXF9lqQO/8pk/OIWZ7PUt2zQtHdKdFUD3Vye/Vk+U5ZsC
UPqg==
X-Gm-Message-State: AC+VfDz/zAf+GfNm7Mq3tJ9blLYhyPrOGoL45oCY/2k+midQeUXbRpnc
IThLPWgOiFOKPzmgS/ECXt4=
X-Google-Smtp-Source: ACHHUZ7fkct3bYWkt1jM4dZQ2poi9OkqrX1+H9AD2bW4I+KRKaKcOVRa6w7eFfCWS4bMxxgeC0EslQ==
X-Received: by 2002:a19:6714:0:b0:4f8:5713:7dd5 with SMTP id
b20-20020a196714000000b004f857137dd5mr16322485lfc.10.1687703829459;
Sun, 25 Jun 2023 07:37:09 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
u11-20020a2ea16b000000b002b3465d344esm739259ljl.44.2023.06.25.07.37.07
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 25 Jun 2023 07:37:08 -0700 (PDT)
Message-ID: <0c4df525-8192-86d2-ece4-564c6726ec82@HIDDEN>
Date: Sun, 25 Jun 2023 21:37:05 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
Content-Language: en-US
To: Ihor Radchenko <yantar92@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
<03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost>
<2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> <871qi2mlnc.fsf@localhost>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <871qi2mlnc.fsf@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 23/06/2023 19:02,
Ihor Radchenko wrote: > 1. Use `org-reload'
instead of load-dir test. Just a reminder: directory test may catch the case
with shadowing by Ort that is not compiled. Version comparison is unable
to detect it.
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.167.45 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.45 listed in wl.mailspike.net]
-1.1 NICE_REPLY_A Looks like a legit reply (A)
X-Debbugs-Envelope-To: 62762
Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 23/06/2023 19:02, Ihor Radchenko wrote: > 1. Use `org-reload'
instead of load-dir test. Just a reminder: directory test may catch the case
with shadowing by Ort that is not compiled. Version comparison is unable
to detect it.
Content analysis details: (1.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.45 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.167.45 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.1 NICE_REPLY_A Looks like a legit reply (A)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
On 23/06/2023 19:02, Ihor Radchenko wrote:
> 1. Use `org-reload' instead of load-dir test.
Just a reminder: directory test may catch the case with shadowing by Ort
that is not compiled. Version comparison is unable to detect it.
> I do not think that we should throw and error. `org-reload' approach
> should hopefully solve the problem with mixed versions.
Have you tested compilation with Org already loaded to Emacs <= 28?
> P.S. I am not sure how to approach this patch in a view of the Emacs
> release process.
Are there other consequences of your changes for incremental rebuilds in
Emacs source tree besides converting error to warning?
My impression is that the most wide spread case is installing the Org
ELPA package should just work in Emacs-29. I am unsure concerning
precise scenario for spacemacs. I have not idea if shadowing by
correctly compiled Org is a frequent issue. Are there other cases
affecting significant number of users and what is behavior for them?
Current warning is so long that it may confuse users who sees only its
final part.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 23 Jun 2023 11:58:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 23 07:58:06 2023
Received: from localhost ([127.0.0.1]:37805 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qCfQR-0004Fx-9Y
for submit <at> debbugs.gnu.org; Fri, 23 Jun 2023 07:58:06 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39865)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qCfQM-0004FO-N2
for 62762 <at> debbugs.gnu.org; Fri, 23 Jun 2023 07:58:02 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id C5DF124002A
for <62762 <at> debbugs.gnu.org>; Fri, 23 Jun 2023 13:57:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1687521472; bh=A9rDARNr27tYSgknKX9TTVRzZ0FAnPhN/r7uoutQGXE=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
b=aDuG7rb5RPgx3GjYCHqmKoJz6B4SKT4hR25Gwc1+vO6AUsW5kBdl2MMxZE2Ad9JYg
+QxqkqeaG2I2ds50NGld7tsxDArG5kLCZSqdMXcsPobdvZ77j5JRDbW/s3hGo6IIbR
yND7acbiyYSpOKgBO9ExbOC6c8BBFsrygiTjwRCyQa+KSCxwTuEFtpp5yEennYcml2
pYFxQTfhrYKf2EjhHHGmRdz8HxfOkh0Ori16ti/6TFhJTljWwGny2Le6/8xTZZ0mFy
Oqc8MONvBAQ45M2/bjzRIB2hgrnwmWtZsCeo2BoFX4npnvlgpU8WSO/KSaOeMfF8oV
9SpYHuMrF4U0A==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4QnbMz0yyFz9rxG;
Fri, 23 Jun 2023 13:57:51 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
<03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN>
<875y93kujy.fsf@localhost>
<2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN>
Date: Fri, 23 Jun 2023 12:02:47 +0000
Message-ID: <871qi2mlnc.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
Max Nikulin <manikulin@HIDDEN> writes:
>> I think we can try to do the following:
>>
>> 1. Use the load-dir test, warn, and try to re-load
>> 2. Use org-assert-version, but downgrade error to simple warning
>
> Ihor, final decision is up to you.
> I think, `org-reload' may be recommended in a warning message. I am
> unsure if `org-reload' called from the assertion while an Org component
> is loaded may not cause a more severe issue. My special concern is
> reloading when new Org is being compiled: is it safe or reloading should
> be suppressed completely?
I am thinking about the following:
1. Use `org-reload' instead of load-dir test. This will re-load all the
currently loaded Org libraries, forcing them to be consistent. This
is necessary because Org does not only rely upon explicit (require
...) statements - we have way too many `declare-function' expecting
other libraries to be loaded by other means.
2. Run `org-reload' _after_ loading current file.
Because (equal (org-release) ,(org-release)) will only ever trigger
during compilation when we (require 'already-compiled-library),
running `org-reload' after loading 'already-compiled-library will
also ensure consistent Org state after (require
'already-compiled-library) is finished.
> I believe, during creation of .elc files, assert macro should signal an
> error since a warning is not enough to prevent loading mixed compilation
> result to next Emacs session. I do not like that currently during
> compiling with old Org loaded, `org-assert-version' causes just a
> warning. Users have difficulties with clean recompiling.
>
> While loading, non-fatal error may be a better option when versions do
> not differ too much.
I do not think that we should throw and error. `org-reload' approach
should hopefully solve the problem with mixed versions. If not, not
throwing an error is still better because mixed compilation actually
works relatively fine in many cases - much better than throwing a hard
error from user perspective. And we will still notify the user that
something is wrong and that random failures are expected.
See the attached tentative patch for bugfix.
P.S. I am not sure how to approach this patch in a view of the Emacs
release process. This is a critical bug, so we aim for bugfix Org
release, but we do not want to make life harder for Emacs devs as well.
--=-=-=
Content-Type: text/x-patch; charset=utf-8
Content-Disposition: inline;
filename=0001-org-assert-version-Demote-to-warning-and-attempt-to-.patch
Content-Transfer-Encoding: quoted-printable
From 5d81ce17ade36135ae405305fb88efd79f97d96f Mon Sep 17 00:00:00 2001
Message-ID: <5d81ce17ade36135ae405305fb88efd79f97d96f.1687521721.git.yantar=
92@HIDDEN>
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Fri, 23 Jun 2023 14:17:05 +0300
Subject: [PATCH] org-assert-version: Demote to warning and attempt to work
around mixed versions
* lisp/org-load.el: New library containing load-related functions and comma=
nds.
(org-require-autoloaded-modules):
(org-reload):
(org-customize):
(org-create-customize-menu):
(org--inhibit-version-check): Move from other files.
(org-assert-version): Move from lisp/org-macs.el, remove error, and
instead try `org-reload' when version mismatch is detected. Update
the warning text, explaining extra scenario when we compile from Git
source with stale .elc files.
* lisp/org-macs.el (org--inhibit-version-check):
(org-assert-version):
(org-find-library-dir): Move from lisp/org-compat.el
* lisp/org.el:
(org-require-autoloaded-modules):
(org-reload):
(org-customize):
(org-create-customize-menu): Move to lisp/org-load.el
* lisp/org-compat.el (org-find-library-dir): Move to lisp/org-macs.el
All the callers to `org-assert-version' are now using
(require 'org-load) instead of (require 'org-macs).
The changes in `org-assert-version' are aiming at 3 goals:
1. Move `org-assert-version' to a new file, not available in older
Org versions. This makes sure that (require 'org-load) either
signals an error or guarantees loading `org-assert-version'
macro. Previous approach with defining the macro in org-macs.el
suffered from byte-compilation silently treating the macro as
undefined function; when org-macs.el was taken from older Org
version and did not define the macro at all.
2. Be less strict and do not throw an error. This is necessary
because mixed Org versions have non-zero chance to produce working
Org, while throwing an error is always hitting users. In this
scenario, pedantic approach makes more harm.
3. Try to recover gracefully from mixed version state by re-loading
Org. This should be considered the last resort and we need to
attract user's attention with a warning, but at least `org-reload'
has a chance to keep Org operational.
An alternative to `org-reload' could also be
"require-with-shadow-check" that ensures that each required library
is taken from the up-to-date `load-path' ordering [1]. However,
Org currently does not rely strictly upon `require' statements.
Org libraries are full of `declare-function' statements that
implicitly assume that certain libraries would be loaded by other
means. So, the alternative approach is less reliable compared to
full Org re-loading.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62762#110
Other discussions of the issue with `org-assert-version' and mixed
install:
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D59882
- https://list.orgmode.org/orgmode/tnm7ui$a8k$1@HIDDEN/
- https://list.orgmode.org/orgmode/87bkonzisl.fsf@HIDDEN/
- https://yhetil.org/emacs-devel/00b52cc1-b0ac-a0c0-c91d-33a7213e9881@HIDDEN=
e/
- https://irreal.org/blog/?p=3D10999
---
lisp/ob-C.el | 2 +-
lisp/ob-R.el | 2 +-
lisp/ob-awk.el | 2 +-
lisp/ob-calc.el | 2 +-
lisp/ob-clojure.el | 2 +-
lisp/ob-comint.el | 2 +-
lisp/ob-core.el | 2 +-
lisp/ob-css.el | 2 +-
lisp/ob-ditaa.el | 2 +-
lisp/ob-dot.el | 2 +-
lisp/ob-emacs-lisp.el | 2 +-
lisp/ob-eshell.el | 2 +-
lisp/ob-eval.el | 2 +-
lisp/ob-exp.el | 2 +-
lisp/ob-forth.el | 2 +-
lisp/ob-fortran.el | 2 +-
lisp/ob-gnuplot.el | 2 +-
lisp/ob-groovy.el | 2 +-
lisp/ob-haskell.el | 2 +-
lisp/ob-java.el | 2 +-
lisp/ob-js.el | 2 +-
lisp/ob-julia.el | 2 +-
lisp/ob-latex.el | 2 +-
lisp/ob-lilypond.el | 2 +-
lisp/ob-lisp.el | 2 +-
lisp/ob-lob.el | 2 +-
lisp/ob-lua.el | 2 +-
lisp/ob-makefile.el | 2 +-
lisp/ob-matlab.el | 2 +-
lisp/ob-maxima.el | 2 +-
lisp/ob-ocaml.el | 2 +-
lisp/ob-octave.el | 2 +-
lisp/ob-org.el | 2 +-
lisp/ob-perl.el | 2 +-
lisp/ob-plantuml.el | 2 +-
lisp/ob-processing.el | 2 +-
lisp/ob-python.el | 2 +-
lisp/ob-ref.el | 2 +-
lisp/ob-ruby.el | 2 +-
lisp/ob-sass.el | 2 +-
lisp/ob-scheme.el | 2 +-
lisp/ob-screen.el | 2 +-
lisp/ob-sed.el | 2 +-
lisp/ob-shell.el | 2 +-
lisp/ob-sql.el | 2 +-
lisp/ob-sqlite.el | 2 +-
lisp/ob-table.el | 2 +-
lisp/ob-tangle.el | 2 +-
lisp/ob.el | 2 +-
lisp/oc-basic.el | 2 +-
lisp/oc-biblatex.el | 2 +-
lisp/oc-bibtex.el | 2 +-
lisp/oc-csl.el | 2 +-
lisp/oc-natbib.el | 2 +-
lisp/oc.el | 2 +-
lisp/ol-bbdb.el | 2 +-
lisp/ol-bibtex.el | 2 +-
lisp/ol-docview.el | 2 +-
lisp/ol-doi.el | 2 +-
lisp/ol-eshell.el | 2 +-
lisp/ol-eww.el | 2 +-
lisp/ol-gnus.el | 2 +-
lisp/ol-info.el | 2 +-
lisp/ol-irc.el | 2 +-
lisp/ol-man.el | 2 +-
lisp/ol-mhe.el | 2 +-
lisp/ol-rmail.el | 2 +-
lisp/ol-w3m.el | 2 +-
lisp/ol.el | 2 +-
lisp/org-agenda.el | 2 +-
lisp/org-archive.el | 2 +-
lisp/org-attach-git.el | 2 +-
lisp/org-attach.el | 2 +-
lisp/org-capture.el | 2 +-
lisp/org-clock.el | 2 +-
lisp/org-compat.el | 3 -
lisp/org-crypt.el | 2 +-
lisp/org-ctags.el | 2 +-
lisp/org-cycle.el | 2 +-
lisp/org-datetree.el | 2 +-
lisp/org-duration.el | 2 +-
lisp/org-element.el | 2 +-
lisp/org-entities.el | 2 +-
lisp/org-faces.el | 2 +-
lisp/org-feed.el | 2 +-
lisp/org-fold-core.el | 2 +-
lisp/org-fold.el | 2 +-
lisp/org-footnote.el | 2 +-
lisp/org-goto.el | 2 +-
lisp/org-habit.el | 2 +-
lisp/org-id.el | 2 +-
lisp/org-indent.el | 2 +-
lisp/org-inlinetask.el | 2 +-
lisp/org-keys.el | 2 +-
lisp/org-lint.el | 2 +-
lisp/org-list.el | 2 +-
lisp/org-load.el | 196 +++++++++++++++++++++++++++++++++++++++++
lisp/org-macro.el | 2 +-
lisp/org-macs.el | 69 +--------------
lisp/org-mobile.el | 2 +-
lisp/org-mouse.el | 2 +-
lisp/org-num.el | 2 +-
lisp/org-pcomplete.el | 2 +-
lisp/org-persist.el | 2 +-
lisp/org-plot.el | 2 +-
lisp/org-protocol.el | 2 +-
lisp/org-refile.el | 2 +-
lisp/org-src.el | 2 +-
lisp/org-table.el | 2 +-
lisp/org-tempo.el | 2 +-
lisp/org-timer.el | 2 +-
lisp/org.el | 85 +-----------------
lisp/ox-ascii.el | 2 +-
lisp/ox-beamer.el | 2 +-
lisp/ox-html.el | 2 +-
lisp/ox-icalendar.el | 2 +-
lisp/ox-koma-letter.el | 2 +-
lisp/ox-latex.el | 2 +-
lisp/ox-man.el | 2 +-
lisp/ox-md.el | 2 +-
lisp/ox-odt.el | 2 +-
lisp/ox-org.el | 2 +-
lisp/ox-publish.el | 2 +-
lisp/ox-texinfo.el | 2 +-
lisp/ox.el | 2 +-
125 files changed, 321 insertions(+), 274 deletions(-)
create mode 100644 lisp/org-load.el
diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 7763c4c07..4251f86bf 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -33,7 +33,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cc-mode)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index f2cc069aa..3d29ebfec 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ob-awk.el b/lisp/ob-awk.el
index e5e42a91d..2add0a329 100644
--- a/lisp/ob-awk.el
+++ b/lisp/ob-awk.el
@@ -33,7 +33,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index 5572ce818..68ca87025 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index d993e0cb7..0047f6dbf 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -46,7 +46,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index adfe31c40..23b457001 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -31,7 +31,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob-core)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e69ce4f1d..a7315130b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -24,7 +24,7 @@ ;;; ob-core.el --- Working with Code Blocks -*- =
lexical-binding: t; -*-
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ob-css.el b/lisp/ob-css.el
index f93c576fc..0dff5525e 100644
--- a/lisp/ob-css.el
+++ b/lisp/ob-css.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
index 622000828..70f5ed679 100644
--- a/lisp/ob-ditaa.el
+++ b/lisp/ob-ditaa.el
@@ -37,7 +37,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-dot.el b/lisp/ob-dot.el
index ecef071a7..b62266503 100644
--- a/lisp/ob-dot.el
+++ b/lisp/ob-dot.el
@@ -40,7 +40,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index f2111d649..3ebc2cf5d 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob-core)
diff --git a/lisp/ob-eshell.el b/lisp/ob-eshell.el
index 95f5777ae..5c82a8f43 100644
--- a/lisp/ob-eshell.el
+++ b/lisp/ob-eshell.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index 07e530772..071102ac9 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(eval-when-compile (require 'subr-x)) ; For `string-empty-p', Emacs < 29
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 4d1b084be..d062c75d1 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -24,7 +24,7 @@ ;;; ob-exp.el --- Exportation of Babel Source Blocks -*- =
lexical-binding: t; -*-
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob-core)
diff --git a/lisp/ob-forth.el b/lisp/ob-forth.el
index e5dcad6d0..e90a6ae13 100644
--- a/lisp/ob-forth.el
+++ b/lisp/ob-forth.el
@@ -33,7 +33,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-fortran.el b/lisp/ob-fortran.el
index 2c050cb18..1e4b62159 100644
--- a/lisp/ob-fortran.el
+++ b/lisp/ob-fortran.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el
index e3e42918c..fbd7f1186 100644
--- a/lisp/ob-gnuplot.el
+++ b/lisp/ob-gnuplot.el
@@ -40,7 +40,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-groovy.el b/lisp/ob-groovy.el
index c0da69fcb..7e3315baa 100644
--- a/lisp/ob-groovy.el
+++ b/lisp/ob-groovy.el
@@ -32,7 +32,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index 7185ed61f..495d18d0e 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -40,7 +40,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 893860526..034034876 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-js.el b/lisp/ob-js.el
index de7ea9131..e0fc0171b 100644
--- a/lisp/ob-js.el
+++ b/lisp/ob-js.el
@@ -39,7 +39,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-julia.el b/lisp/ob-julia.el
index cb5c7fa3b..9895aa10f 100644
--- a/lisp/ob-julia.el
+++ b/lisp/ob-julia.el
@@ -32,7 +32,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index ce39628d6..68b584523 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -31,7 +31,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 9693b89e2..75470c71f 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -33,7 +33,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 048ef883c..268129460 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -37,7 +37,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index f77bda73d..e8ceb42e3 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -24,7 +24,7 @@ ;;; ob-lob.el --- Functions Supporting the Library of Bab=
el -*- lexical-binding:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ob-lua.el b/lisp/ob-lua.el
index 81521d9e0..6c7aeb2f5 100644
--- a/lisp/ob-lua.el
+++ b/lisp/ob-lua.el
@@ -36,7 +36,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-makefile.el b/lisp/ob-makefile.el
index 25306159b..31c4a509e 100644
--- a/lisp/ob-makefile.el
+++ b/lisp/ob-makefile.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-matlab.el b/lisp/ob-matlab.el
index 43344495d..38c7b539f 100644
--- a/lisp/ob-matlab.el
+++ b/lisp/ob-matlab.el
@@ -36,7 +36,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index d1d7c7424..0673e0b7f 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -32,7 +32,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
index 09224b98b..7d89f6141 100644
--- a/lisp/ob-ocaml.el
+++ b/lisp/ob-ocaml.el
@@ -36,7 +36,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-octave.el b/lisp/ob-octave.el
index 1de263a52..9261404d4 100644
--- a/lisp/ob-octave.el
+++ b/lisp/ob-octave.el
@@ -30,7 +30,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-org.el b/lisp/ob-org.el
index 1bf02b461..79084e2f2 100644
--- a/lisp/ob-org.el
+++ b/lisp/ob-org.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-perl.el b/lisp/ob-perl.el
index c8cff5da5..45e31fd32 100644
--- a/lisp/ob-perl.el
+++ b/lisp/ob-perl.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index 3202c6e41..705925cd7 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -35,7 +35,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-processing.el b/lisp/ob-processing.el
index 4eeaf98e0..558b4099d 100644
--- a/lisp/ob-processing.el
+++ b/lisp/ob-processing.el
@@ -52,7 +52,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index c19af0ab3..1512d3234 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index 2eae3690d..51ecd51fe 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -50,7 +50,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob-core)
diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
index b94bc73dd..390e32074 100644
--- a/lisp/ob-ruby.el
+++ b/lisp/ob-ruby.el
@@ -36,7 +36,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-sass.el b/lisp/ob-sass.el
index 1498b931e..c8970b2a6 100644
--- a/lisp/ob-sass.el
+++ b/lisp/ob-sass.el
@@ -39,7 +39,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index ef41a2ec4..0d1ec142a 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -39,7 +39,7 @@ ;;; Requirements:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-screen.el b/lisp/ob-screen.el
index 269538e79..f7f1a1d67 100644
--- a/lisp/ob-screen.el
+++ b/lisp/ob-screen.el
@@ -35,7 +35,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-sed.el b/lisp/ob-sed.el
index 6469901fd..1b281c80d 100644
--- a/lisp/ob-sed.el
+++ b/lisp/ob-sed.el
@@ -41,7 +41,7 @@ ;;; Usage:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
index 2c30a2605..b5deaf61b 100644
--- a/lisp/ob-shell.el
+++ b/lisp/ob-shell.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index f73e7003f..377e31f0f 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -71,7 +71,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 526b73ebd..533bee2a1 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob)
diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 5c91f33f8..88d74816f 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -54,7 +54,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ob-core)
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index e63bde89f..824dc963e 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ob.el b/lisp/ob.el
index 4444ced58..0a81584f3 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -23,7 +23,7 @@ ;;; ob.el --- Working with Code Blocks in Org -*- =
lexical-binding: t; -*-
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index 1c8c37aa9..105e759ba 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -66,7 +66,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'bibtex)
diff --git a/lisp/oc-biblatex.el b/lisp/oc-biblatex.el
index b2d31f0f6..bb6d6dca8 100644
--- a/lisp/oc-biblatex.el
+++ b/lisp/oc-biblatex.el
@@ -63,7 +63,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'map)
diff --git a/lisp/oc-bibtex.el b/lisp/oc-bibtex.el
index d5e5490ed..a5a311224 100644
--- a/lisp/oc-bibtex.el
+++ b/lisp/oc-bibtex.el
@@ -36,7 +36,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'oc)
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 2b00cb599..65e821593 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -112,7 +112,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/oc-natbib.el b/lisp/oc-natbib.el
index 855be2a5c..5900d720b 100644
--- a/lisp/oc-natbib.el
+++ b/lisp/oc-natbib.el
@@ -43,7 +43,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'oc)
diff --git a/lisp/oc.el b/lisp/oc.el
index 8a7b66209..e62088e11 100644
--- a/lisp/oc.el
+++ b/lisp/oc.el
@@ -61,7 +61,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-compat)
diff --git a/lisp/ol-bbdb.el b/lisp/ol-bbdb.el
index 47bd9d98c..a0ec6a79a 100644
--- a/lisp/ol-bbdb.el
+++ b/lisp/ol-bbdb.el
@@ -93,7 +93,7 @@ ;;; Commentary:
;;
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ol-bibtex.el b/lisp/ol-bibtex.el
index fd9517233..dd11b422d 100644
--- a/lisp/ol-bibtex.el
+++ b/lisp/ol-bibtex.el
@@ -107,7 +107,7 @@ ;;; History:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'bibtex)
diff --git a/lisp/ol-docview.el b/lisp/ol-docview.el
index a9cd9b995..fd4525940 100644
--- a/lisp/ol-docview.el
+++ b/lisp/ol-docview.el
@@ -42,7 +42,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'doc-view)
diff --git a/lisp/ol-doi.el b/lisp/ol-doi.el
index 971b05087..e24c4b463 100644
--- a/lisp/ol-doi.el
+++ b/lisp/ol-doi.el
@@ -26,7 +26,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-eshell.el b/lisp/ol-eshell.el
index b7d3baf38..67b79538f 100644
--- a/lisp/ol-eshell.el
+++ b/lisp/ol-eshell.el
@@ -23,7 +23,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'eshell)
diff --git a/lisp/ol-eww.el b/lisp/ol-eww.el
index ee970b6aa..1d404b6de 100644
--- a/lisp/ol-eww.el
+++ b/lisp/ol-eww.el
@@ -45,7 +45,7 @@ ;;; Commentary:
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el
index 7c07ce045..6a4362bc5 100644
--- a/lisp/ol-gnus.el
+++ b/lisp/ol-gnus.el
@@ -31,7 +31,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'gnus-sum)
diff --git a/lisp/ol-info.el b/lisp/ol-info.el
index ad9e4a12b..7df698daa 100644
--- a/lisp/ol-info.el
+++ b/lisp/ol-info.el
@@ -30,7 +30,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-irc.el b/lisp/ol-irc.el
index 3760644e8..b14d3c47f 100644
--- a/lisp/ol-irc.el
+++ b/lisp/ol-irc.el
@@ -48,7 +48,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-man.el b/lisp/ol-man.el
index 40fdc8f92..96c991b21 100644
--- a/lisp/ol-man.el
+++ b/lisp/ol-man.el
@@ -24,7 +24,7 @@ ;;; ol-man.el --- Links to man pages -*- lexical-binding:=
t; -*-
;;
;;; Commentary:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-mhe.el b/lisp/ol-mhe.el
index 403b5a254..16b1967f8 100644
--- a/lisp/ol-mhe.el
+++ b/lisp/ol-mhe.el
@@ -30,7 +30,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/ol-rmail.el b/lisp/ol-rmail.el
index 287779828..f95b6999c 100644
--- a/lisp/ol-rmail.el
+++ b/lisp/ol-rmail.el
@@ -30,7 +30,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol-w3m.el b/lisp/ol-w3m.el
index 6fb01a60d..6d14e6ebc 100644
--- a/lisp/ol-w3m.el
+++ b/lisp/ol-w3m.el
@@ -41,7 +41,7 @@ ;;; Acknowledgments:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ol)
diff --git a/lisp/ol.el b/lisp/ol.el
index 9ad191c8f..e5e8de80f 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-compat)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index d3e616431..6ff3b3cb0 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -45,7 +45,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index e74c59a51..3f74e6d14 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-attach-git.el b/lisp/org-attach-git.el
index 4763aefd4..2c9242d70 100644
--- a/lisp/org-attach-git.el
+++ b/lisp/org-attach-git.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-attach)
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index e8b27751e..428c12068 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -34,7 +34,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index a696c615b..cf487ac19 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -47,7 +47,7 @@ ;;; TODO
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index d7fe14cd5..77225d2d6 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index d5bf2191a..360143018 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -1176,9 +1176,6 @@ (defun org-move-to-column (column &optional force _bu=
ffer)
buffer-invisibility-spec)))
(move-to-column column force)))
=20
-(defmacro org-find-library-dir (library)
- `(file-name-directory (or (locate-library ,library) "")))
-
(defun org-count-lines (s)
"How many lines in string S?"
(let ((start 0) (n 1))
diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index b5df115cf..b6a306371 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -54,7 +54,7 @@ ;;; Thanks:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el
index 5dd2bfd59..8ff2563e1 100644
--- a/lisp/org-ctags.el
+++ b/lisp/org-ctags.el
@@ -135,7 +135,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(eval-when-compile (require 'cl-lib))
diff --git a/lisp/org-cycle.el b/lisp/org-cycle.el
index 90fc95f41..85e94657f 100644
--- a/lisp/org-cycle.el
+++ b/lisp/org-cycle.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-datetree.el b/lisp/org-datetree.el
index 035ef047a..d3491324d 100644
--- a/lisp/org-datetree.el
+++ b/lisp/org-datetree.el
@@ -30,7 +30,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-duration.el b/lisp/org-duration.el
index 2919efd4c..2adddcc1b 100644
--- a/lisp/org-duration.el
+++ b/lisp/org-duration.el
@@ -51,7 +51,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index df43ebcf0..7397cb6cb 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -58,7 +58,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'avl-tree)
diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index 61083022b..7125a5c77 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(declare-function org-mode "org" ())
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 594c9a6e7..5c1bd50a1 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(defgroup org-faces nil
diff --git a/lisp/org-feed.el b/lisp/org-feed.el
index f0b294b4a..43c035ad6 100644
--- a/lisp/org-feed.el
+++ b/lisp/org-feed.el
@@ -88,7 +88,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el
index 6c17b00fa..1ba7601f1 100644
--- a/lisp/org-fold-core.el
+++ b/lisp/org-fold-core.el
@@ -270,7 +270,7 @@ ;;; Performance considerations
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-fold.el b/lisp/org-fold.el
index 1b7ca22b0..2e63f5100 100644
--- a/lisp/org-fold.el
+++ b/lisp/org-fold.el
@@ -42,7 +42,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el
index 6bdd0b32f..7874a4af1 100644
--- a/lisp/org-footnote.el
+++ b/lisp/org-footnote.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
;;;; Declarations
diff --git a/lisp/org-goto.el b/lisp/org-goto.el
index 00bf5d46a..2da5a86e2 100644
--- a/lisp/org-goto.el
+++ b/lisp/org-goto.el
@@ -22,7 +22,7 @@ ;;; org-goto.el --- Fast navigation in an Org buffer -*-=
lexical-binding: t; -*
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index fb6a48b5f..a835ff270 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-id.el b/lisp/org-id.el
index 490e4ddee..d7b4dd338 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -70,7 +70,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-indent.el b/lisp/org-indent.el
index fe5233878..0a0019a44 100644
--- a/lisp/org-indent.el
+++ b/lisp/org-indent.el
@@ -36,7 +36,7 @@ ;;; Commentary:
;;
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index cb7fdf88b..1fb16a2f8 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -78,7 +78,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 37a150bb7..b5c576b2a 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-lint.el b/lisp/org-lint.el
index 0e2967b6c..e6c4d088f 100644
--- a/lisp/org-lint.el
+++ b/lisp/org-lint.el
@@ -85,7 +85,7 @@ ;;; Commentary:
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-list.el b/lisp/org-list.el
index 1fc99d070..63ff65bca 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -76,7 +76,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-load.el b/lisp/org-load.el
new file mode 100644
index 000000000..c618452f2
--- /dev/null
+++ b/lisp/org-load.el
@@ -0,0 +1,196 @@
+;;; org-load.el --- Functions and commands that load Org mode -*- =
lexical-binding: t; -*-
+
+;; Copyright (C) 2023-2023 Free Software Foundation, Inc.
+
+;; Author: Ihor Radchenko <yantar92 at gmail dot com>
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+;;
+;; This file contains commands and functions dealing with loading
+;; various parts of Org and checking consistency of the Org libraries.
+
+(require 'org-macs)
+
+(defun org-require-autoloaded-modules ()
+ (interactive)
+ (mapc #'require
+ '(org-agenda org-archive org-attach org-clock org-colview org-id
+ org-table org-timer)))
+
+;;;###autoload
+(defun org-reload (&optional uncompiled)
+ "Reload all Org Lisp files.
+With prefix arg UNCOMPILED, load the uncompiled versions."
+ (interactive "P")
+ (require 'loadhist)
+ (let* ((org-dir (org-find-library-dir "org"))
+ (contrib-dir (or (org-find-library-dir "org-contribdir") org-dir))
+ (feature-re "^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?")
+ (remove-re (format "\\`%s\\'"
+ (regexp-opt '("org" "org-loaddefs" "org-version"))))
+ (feats (delete-dups
+ (mapcar 'file-name-sans-extension
+ (mapcar 'file-name-nondirectory
+ (delq nil
+ (mapcar 'feature-file
+ features))))))
+ (lfeat (append
+ (sort
+ (setq feats
+ (delq nil (mapcar
+ (lambda (f)
+ (if (and (string-match feature-re f)
+ (not (string-match remove-re f)))
+ f nil))
+ feats)))
+ 'string-lessp)
+ (list "org-version" "org")))
+ (load-suffixes (if uncompiled (reverse load-suffixes) load-suffixes))
+ load-uncore load-misses)
+ (setq load-misses
+ (delq t
+ (mapcar (lambda (f)
+ (or (org-load-noerror-mustsuffix (concat org-dir f))
+ (and (string=3D org-dir contrib-dir)
+ (org-load-noerror-mustsuffix (concat contrib-dir f)))
+ (and (org-load-noerror-mustsuffix (concat (org-find-library-dir f=
) f))
+ (push f load-uncore)
+ t)
+ f))
+ lfeat)))
+ (when load-uncore
+ (message "The following feature%s found in load-path, please check i=
f that's correct:\n%s"
+ (if (> (length load-uncore) 1) "s were" " was")
+ (reverse load-uncore)))
+ (if load-misses
+ (message "Some error occurred while reloading Org feature%s\n%s\nPlease c=
heck *Messages*!\n%s"
+ (if (> (length load-misses) 1) "s" "") load-misses (org-version nil 'fu=
ll))
+ (message "Successfully reloaded Org\n%s" (org-version nil 'full)))))
+
+;;;###autoload
+(defun org-customize ()
+ "Call the customize function with org as argument."
+ (interactive)
+ (org-load-modules-maybe)
+ (org-require-autoloaded-modules)
+ (customize-browse 'org))
+
+(defun org-create-customize-menu ()
+ "Create a full customization menu for Org mode, insert it into the menu."
+ (interactive)
+ (org-load-modules-maybe)
+ (org-require-autoloaded-modules)
+ (easy-menu-change
+ '("Org") "Customize"
+ `(["Browse Org group" org-customize t]
+ "--"
+ ,(customize-menu-create 'org)
+ ["Set" Custom-set t]
+ ["Save" Custom-save t]
+ ["Reset to Current" Custom-reset-current t]
+ ["Reset to Saved" Custom-reset-saved t]
+ ["Reset to Standard Settings" Custom-reset-standard t]))
+ (message "\"Org\"-menu now contains full customization menu"))
+
+;;; Org version verification.
+
+(defvar org--inhibit-version-check nil
+ "When non-nil, skip the detection of mixed-versions situations.
+For internal use only. See Emacs bug #62762.
+This variable is only supposed to be changed by Emacs build scripts.
+When nil, Org tries to detect when Org source files were compiled with
+a different version of Org (which tends to lead to incorrect `.elc' files),
+or when the current Emacs session has loaded a mix of files from different
+Org versions (typically the one bundled with Emacs and another one install=
ed
+from GNU ELPA), which can happen if some parts of Org were loaded before
+`load-path' was changed (e.g. before the GNU-ELPA-installed Org is activat=
ed
+by `package-activate-all').")
+(defmacro org-assert-version ()
+ "Check compile time and runtime version match.
+Warn, and attempt to fix mixed version, if any."
+ ;; We intentionally use a more permissive `org-release' instead of
+ ;; `org-git-version' to work around deficiencies in Elisp
+ ;; compilation after pulling latest changes. Unchanged files will
+ ;; not be re-compiled and thus their macro-expanded
+ ;; `org-assert-version' calls would fail using strict
+ ;; `org-git-version' check because the generated Org version strings
+ ;; will not match.
+ `(unless (or org--inhibit-version-check (equal (org-release) ,(org-relea=
se)))
+ (warn "Org version mismatch. Random Org errors may occur.
+This warning usually appears when a built-in Org version is loaded
+prior to the more recent Org version.
+
+Version mismatch is commonly encountered in the following situations:
+
+1. Some compiled Org libraries are not re-compiled after Org update.
+
+ It is recommended to re-install Org, or, if Org is loaded from git
+ repo, to run
+
+ make clean; make autoloads
+
+2. Emacs is loaded using literate Org config and more recent Org
+ version is loaded inside the file loaded by `org-babel-load-file'.
+ `org-babel-load-file' triggers the built-in Org version clashing
+ the newer Org version attempt to be loaded later.
+
+ It is recommended to move the Org loading code before the
+ `org-babel-load-file' call.
+
+3. New Org version is loaded manually by setting `load-path', but some
+ other package depending on Org is loaded before the `load-path' is
+ configured.
+ This \"other package\" is triggering built-in Org version, again
+ causing the version mismatch.
+
+ It is recommended to set `load-path' as early in the config as
+ possible.
+
+4. New Org version is loaded using straight.el package manager and
+ other package depending on Org is loaded before straight triggers
+ loading of the newer Org version.
+
+ It is recommended to put
+
+ %s
+
+ early in the config. Ideally, right after the straight.el
+ bootstrap. Moving `use-package' :straight declaration may not be
+ sufficient if the corresponding `use-package' statement is
+ deferring the loading."
+ ;; Avoid `warn' replacing "'" with "=E2=80=99" (see `format-mes=
sage').
+ "(straight-use-package 'org)")
+ ;; Try to re-load Org.
+ ;; Do the re-loading after the current, faulty file is loaded.
+ ;; The current file may still fail to load - situation we cannot
+ ;; work around.
+ ;; We re-load the whole Org here because Org commonly uses
+ ;; `declare-function' statements and thus more granular approach,
+ ;; like suggested in
+ ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62762#110
+ ;; will not be as reliable.
+ ;; Note that this clause will never run during compilation
+ ;; because version check can only trigger in already compiled
+ ;; files with macro expanded differently during compilation and
+ ;; during loading. (equal (org-release) ,(org-release)) is
+ ;; always t when compiling current `load-file-name'.
+ (eval-after-load load-file-name (org-reload t))))
+
+(provide 'org-load)
+
+;;; org-load.el ends here
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 481e431c2..98706f676 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -47,7 +47,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 1552675f8..984e7c023 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -34,72 +34,6 @@ ;;; Code:
(require 'cl-lib)
(require 'format-spec)
=20
-;;; Org version verification.
-
-(defvar org--inhibit-version-check nil
- "When non-nil, skip the detection of mixed-versions situations.
-For internal use only. See Emacs bug #62762.
-This variable is only supposed to be changed by Emacs build scripts.
-When nil, Org tries to detect when Org source files were compiled with
-a different version of Org (which tends to lead to incorrect `.elc' files),
-or when the current Emacs session has loaded a mix of files from different
-Org versions (typically the one bundled with Emacs and another one install=
ed
-from GNU ELPA), which can happen if some parts of Org were loaded before
-`load-path' was changed (e.g. before the GNU-ELPA-installed Org is activat=
ed
-by `package-activate-all').")
-(defmacro org-assert-version ()
- "Assert compile time and runtime version match."
- ;; We intentionally use a more permissive `org-release' instead of
- ;; `org-git-version' to work around deficiencies in Elisp
- ;; compilation after pulling latest changes. Unchanged files will
- ;; not be re-compiled and thus their macro-expanded
- ;; `org-assert-version' calls would fail using strict
- ;; `org-git-version' check because the generated Org version strings
- ;; will not match.
- `(unless (or org--inhibit-version-check (equal (org-release) ,(org-relea=
se)))
- (warn "Org version mismatch. Org loading aborted.
-This warning usually appears when a built-in Org version is loaded
-prior to the more recent Org version.
-
-Version mismatch is commonly encountered in the following situations:
-
-1. Emacs is loaded using literate Org config and more recent Org
- version is loaded inside the file loaded by `org-babel-load-file'.
- `org-babel-load-file' triggers the built-in Org version clashing
- the newer Org version attempt to be loaded later.
-
- It is recommended to move the Org loading code before the
- `org-babel-load-file' call.
-
-2. New Org version is loaded manually by setting `load-path', but some
- other package depending on Org is loaded before the `load-path' is
- configured.
- This \"other package\" is triggering built-in Org version, again
- causing the version mismatch.
-
- It is recommended to set `load-path' as early in the config as
- possible.
-
-3. New Org version is loaded using straight.el package manager and
- other package depending on Org is loaded before straight triggers
- loading of the newer Org version.
-
- It is recommended to put
-
- %s
-
- early in the config. Ideally, right after the straight.el
- bootstrap. Moving `use-package' :straight declaration may not be
- sufficient if the corresponding `use-package' statement is
- deferring the loading."
- ;; Avoid `warn' replacing "'" with "=E2=80=99" (see `format-mes=
sage').
- "(straight-use-package 'org)")
- (error "Org version mismatch. Make sure that correct `load-path' is =
set early in init.el")))
-
-;; We rely on org-macs when generating Org version. Checking Org
-;; version here will interfere with Org build process.
-;; (org-assert-version)
-
(declare-function org-mode "org" ())
(declare-function org-agenda-files "org" (&optional unrestricted archives))
(declare-function org-time-string-to-seconds "org" (s))
@@ -215,6 +149,9 @@ (defmacro org-eval-in-environment (environment form)
(declare (debug (form form)) (indent 1) (obsolete cl-progv "2021"))
`(eval (list 'let ,environment ',form)))
=20
+(defmacro org-find-library-dir (library)
+ `(file-name-directory (or (locate-library ,library) "")))
+
;;;###autoload
(defmacro org-load-noerror-mustsuffix (file)
"Load FILE with optional arguments NOERROR and MUSTSUFFIX."
diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el
index 01395a4b6..17cb2f881 100644
--- a/lisp/org-mobile.el
+++ b/lisp/org-mobile.el
@@ -31,7 +31,7 @@ ;;; Commentary:
;; iPhone and Android - any external viewer/flagging/editing
;; application that uses the same conventions could be used.
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-mouse.el b/lisp/org-mouse.el
index 3b2c4cba6..90779be3f 100644
--- a/lisp/org-mouse.el
+++ b/lisp/org-mouse.el
@@ -136,7 +136,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-num.el b/lisp/org-num.el
index cbe5e455e..9d3f14402 100644
--- a/lisp/org-num.el
+++ b/lisp/org-num.el
@@ -61,7 +61,7 @@ ;;; Commentary:
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-pcomplete.el b/lisp/org-pcomplete.el
index 0567052c0..e5cc707e7 100644
--- a/lisp/org-pcomplete.el
+++ b/lisp/org-pcomplete.el
@@ -26,7 +26,7 @@ ;;; Code:
=20
;;;; Require other packages
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-macs)
diff --git a/lisp/org-persist.el b/lisp/org-persist.el
index 01078f459..a43853d3c 100644
--- a/lisp/org-persist.el
+++ b/lisp/org-persist.el
@@ -149,7 +149,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org-compat)
diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index fe61e9ace..0eb603dc4 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -31,7 +31,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 2b07a377e..fc6d23f5e 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -128,7 +128,7 @@ ;;; Commentary:
;;
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 5a41c022f..947a593df 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -25,7 +25,7 @@ ;;; Commentary:
;; Org Refile allows you to refile subtrees to various locations.
=20
;;; Code:
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'org)
diff --git a/lisp/org-src.el b/lisp/org-src.el
index aadd8eba5..793d89ca1 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -31,7 +31,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 83bad3f3a..4add43e6d 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -34,7 +34,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index 81ec8fdcc..4d0847dcd 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -38,7 +38,7 @@ ;;; Commentary:
;;
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'tempo)
diff --git a/lisp/org-timer.el b/lisp/org-timer.el
index 919630e69..b4d24f45c 100644
--- a/lisp/org-timer.el
+++ b/lisp/org-timer.el
@@ -35,7 +35,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/org.el b/lisp/org.el
index 2e26c08e5..3966e9b3e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -71,7 +71,7 @@ (defvar org-inlinetask-min-level)
=20
;;;; Require other packages
=20
-(require 'org-compat)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
@@ -18278,89 +18278,6 @@ (defun org-install-agenda-files-menu ()
;; Prevent initialization from failing.
(ignore-errors (org-agenda-files t)))))))))
=20
-;;;; Documentation
-
-(defun org-require-autoloaded-modules ()
- (interactive)
- (mapc #'require
- '(org-agenda org-archive org-attach org-clock org-colview org-id
- org-table org-timer)))
-
-;;;###autoload
-(defun org-reload (&optional uncompiled)
- "Reload all Org Lisp files.
-With prefix arg UNCOMPILED, load the uncompiled versions."
- (interactive "P")
- (require 'loadhist)
- (let* ((org-dir (org-find-library-dir "org"))
- (contrib-dir (or (org-find-library-dir "org-contribdir") org-dir))
- (feature-re "^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?")
- (remove-re (format "\\`%s\\'"
- (regexp-opt '("org" "org-loaddefs" "org-version"))))
- (feats (delete-dups
- (mapcar 'file-name-sans-extension
- (mapcar 'file-name-nondirectory
- (delq nil
- (mapcar 'feature-file
- features))))))
- (lfeat (append
- (sort
- (setq feats
- (delq nil (mapcar
- (lambda (f)
- (if (and (string-match feature-re f)
- (not (string-match remove-re f)))
- f nil))
- feats)))
- 'string-lessp)
- (list "org-version" "org")))
- (load-suffixes (if uncompiled (reverse load-suffixes) load-suffixes))
- load-uncore load-misses)
- (setq load-misses
- (delq t
- (mapcar (lambda (f)
- (or (org-load-noerror-mustsuffix (concat org-dir f))
- (and (string=3D org-dir contrib-dir)
- (org-load-noerror-mustsuffix (concat contrib-dir f)))
- (and (org-load-noerror-mustsuffix (concat (org-find-library-dir f=
) f))
- (push f load-uncore)
- t)
- f))
- lfeat)))
- (when load-uncore
- (message "The following feature%s found in load-path, please check i=
f that's correct:\n%s"
- (if (> (length load-uncore) 1) "s were" " was")
- (reverse load-uncore)))
- (if load-misses
- (message "Some error occurred while reloading Org feature%s\n%s\nPlease c=
heck *Messages*!\n%s"
- (if (> (length load-misses) 1) "s" "") load-misses (org-version nil 'fu=
ll))
- (message "Successfully reloaded Org\n%s" (org-version nil 'full)))))
-
-;;;###autoload
-(defun org-customize ()
- "Call the customize function with org as argument."
- (interactive)
- (org-load-modules-maybe)
- (org-require-autoloaded-modules)
- (customize-browse 'org))
-
-(defun org-create-customize-menu ()
- "Create a full customization menu for Org mode, insert it into the menu."
- (interactive)
- (org-load-modules-maybe)
- (org-require-autoloaded-modules)
- (easy-menu-change
- '("Org") "Customize"
- `(["Browse Org group" org-customize t]
- "--"
- ,(customize-menu-create 'org)
- ["Set" Custom-set t]
- ["Save" Custom-save t]
- ["Reset to Current" Custom-reset-current t]
- ["Reset to Saved" Custom-reset-saved t]
- ["Reset to Standard Settings" Custom-reset-standard t]))
- (message "\"Org\"-menu now contains full customization menu"))
-
;;;; Miscellaneous stuff
=20
;;; Generally useful functions
diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 692dd216d..13dd7439f 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -28,7 +28,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ox)
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 689bf1559..d00baa41d 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -30,7 +30,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index b27254b8a..93d8fb399 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -31,7 +31,7 @@ ;;; Code:
=20
;;; Dependencies
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 81a77a770..16d88a6f3 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -32,7 +32,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-koma-letter.el b/lisp/ox-koma-letter.el
index 33eb0597b..9cd48c1f5 100644
--- a/lisp/ox-koma-letter.el
+++ b/lisp/ox-koma-letter.el
@@ -165,7 +165,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 768bf402b..2be4ef34c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -27,7 +27,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index bb716f7b9..3b703fd1f 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -37,7 +37,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index 5be0ca22e..9e368ba0f 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -29,7 +29,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index dd96ed8e0..b0c0b234a 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -25,7 +25,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-org.el b/lisp/ox-org.el
index ed72cf4f2..98e4682b4 100644
--- a/lisp/ox-org.el
+++ b/lisp/ox-org.el
@@ -25,7 +25,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'ox)
diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index f9c3877d7..23cd7f325 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -38,7 +38,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 5befcac1c..0e5e696db 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -26,7 +26,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
diff --git a/lisp/ox.el b/lisp/ox.el
index 6f819def9..f979c3eef 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -72,7 +72,7 @@ ;;; Commentary:
=20
;;; Code:
=20
-(require 'org-macs)
+(require 'org-load)
(org-assert-version)
=20
(require 'cl-lib)
--=20
2.41.0
--=-=-=
Content-Type: text/plain
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 15 May 2023 15:00:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 15 11:00:32 2023
Received: from localhost ([127.0.0.1]:44144 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pyZga-0002DE-Ts
for submit <at> debbugs.gnu.org; Mon, 15 May 2023 11:00:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51650)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pyZgW-0002Cr-Ai
for 62762 <at> debbugs.gnu.org; Mon, 15 May 2023 11:00:28 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD4BA4434A9;
Mon, 15 May 2023 11:00:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8DD894434A5;
Mon, 15 May 2023 11:00:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1684162817;
bh=rBZwEnkO7nXBSJSJxBvL+WGcF37iUCjOmewh9HitYyA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=BXce+ks4g63FFuc2vM6RT4jmy0s0uTEF8J+n2kZ3n0jBWUYSPu9J5ZB6IK+31AvEu
KEd573q7RC/eMATzo/V5UZriR0IU1BdYpMpnqdvX3EhFgZE65G7KaWE6w8jpMVzwqO
OmQvvuV49qD0UXS2jCn4MrNQu2NxaYdLZo15VBk+IJ3EvmR8STdMSFyfTPC06jyfdM
eUS3PWNRufXhxhIdlSu7Dgu77qCzjiCNYAFh7mVsT1MG5JYjgUGld8lQNI/I7QicF+
V7De9AedkDSH1yeaGedVRSd764ZsEbB5tEIOCQ694M70m/2QS9tBu8vmz78dWx4BKQ
IYZiQdudokxvQ==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4F0CB120D76;
Mon, 15 May 2023 11:00:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: circular dependencies in elisp files and make
In-Reply-To: <e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN> (Max Nikulin's
message of "Mon, 15 May 2023 17:11:25 +0700")
Message-ID: <jwv8rdp4pqn.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN>
<83v8h7hxlj.fsf@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN>
<fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN>
<83y1lu505p.fsf@HIDDEN>
<9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN>
<83ttwhbn7b.fsf@HIDDEN>
<9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN>
<83sfc1bkt3.fsf@HIDDEN>
<cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN>
<83zg68afn9.fsf@HIDDEN>
<16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN>
<jwvpm74i903.fsf-monnier+emacs@HIDDEN>
<e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN>
Date: Mon, 15 May 2023 11:00:15 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.049 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> You are right when dependency graph is a tree. You provided an
> example of circular dependency in lisp/vc/ediff-util.el.
[...]
> Due to these reasons I prefer 2 stage incremental build.
My intuition tells me it's probably not going to result in a good
trade-off, which is why I haven't worked on it so far.
But you don't need to try and convince me (or anyone else).
Instead, just go and implement it.
If you prove my intuition wrong, then we'll all be happy.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 May 2023 13:00:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 15 09:00:39 2023 Received: from localhost ([127.0.0.1]:42978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pyXod-0006uU-E1 for submit <at> debbugs.gnu.org; Mon, 15 May 2023 09:00:39 -0400 Received: from mail-lj1-f181.google.com ([209.85.208.181]:49269) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pyXoY-0006uD-3p for 62762 <at> debbugs.gnu.org; Mon, 15 May 2023 09:00:37 -0400 Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2ac8091351eso133642221fa.2 for <62762 <at> debbugs.gnu.org>; Mon, 15 May 2023 06:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684155628; x=1686747628; 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=A/w8HPap1uNn1vmIDPlmndaq6K+BBE4rqxLj4TZYDVQ=; b=UDRMVsC3op5UDtagej+BL45CKFlPAKcduef9ptTfzQDClNjCBr2srtHilVE8IiLYAf YZOOySgqlEmcbteH3+d7xOn2aYyFIQtdFaSFJ49xOvV8QfEWo3H0JQ6eWICLQxPZdB1I yb27IcOVYeJ4sPbvyNElJklY18SIk0us75FstAS+PQ43Trxhhgm3o6Fb6McAoDkM0w8g HSepR2lxC0ydtIAn0kD0SXfVgCaD0Y0pXz2yoI23w0SlW3f4X2Ctf60bOteYLs2t0fWy ULeBvHsycy0z06tc3k5n0/mg+QGyhk1Pdieo8wGWqd+oElri9AQQTba9olZ13K7cBK/U 2/SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684155628; x=1686747628; 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=A/w8HPap1uNn1vmIDPlmndaq6K+BBE4rqxLj4TZYDVQ=; b=dyc8r/JHjGRcS4O9nCX+liwKxpqu8uwhFfXGFy3xOXsVUDqH2OgF/uARueFyZCAJdm oLQr2J75Vb0jFvTPhVcTB2ySHc5izuIfddBQZPwe5jMenp/KbmXwD2nHSuQDZjEfNfZq CsRsNl5ZRQLLW6IOWpbfxwW6I3nTSLa7w4yJ+vj/sWVo7drKQsijO26hQF7dqC88U/5i zHZeKxM9vlFC57f30FCAw/VBjGfZsLeaaWsZES+pWPyMkUQOR5JseXz054/xEllnbCvj ys/XkSKRBS1w7xS16QGxOrCAI1p/H5ydC5jwPZVPTNGhKA+NvlJMMk/QRneT1/w7Mnt/ uejg== X-Gm-Message-State: AC+VfDz1S1fHteJvdM0ZjtMwwScLQ1zbJiL9yNZiBJPHqOKeaeQ4evDx kgNC7+QJwytUPHeJlyAenMU= X-Google-Smtp-Source: ACHHUZ7C/+nOo64o8HfN0AtAqjE2aPKZuUQDddwGZiUnbfFRSAiC/YwkqPSZ1YjupIFrTk1XwS0qlA== X-Received: by 2002:a2e:9050:0:b0:2ad:af50:6ecb with SMTP id n16-20020a2e9050000000b002adaf506ecbmr5879113ljg.14.1684155627788; Mon, 15 May 2023 06:00:27 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id z13-20020a05651c022d00b002a8b8baf542sm3805166ljn.126.2023.05.15.06.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 06:00:27 -0700 (PDT) Message-ID: <9505b1e9-1aee-ddb6-6dcd-063251c7cdee@HIDDEN> Date: Mon, 15 May 2023 20:00:25 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <jwvpm74i903.fsf-monnier+emacs@HIDDEN> <e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN> <83mt25264i.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83mt25264i.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 15/05/2023 18:20, Eli Zaretskii wrote: >> Date: Mon, 15 May 2023 17:11:25 +0700 From: Max Nikulin >> >> I see just one case when it may lead to incomplete >> rebuild: a.el uses a function from al.el without (require 'al) and >> autoload cookie is missed in al.el. > > This can happen when we use 'declare-function'. Sorry, my bad. When a.el uses a *macro* from al.el then, instead of macro expansion result, function call appears in a.elc. Anyway by this sentence I was trying to convince that it is enough to have loaddefs as order-only dependency. What would be more interesting is an example when an .elc file *must* be recompiled in response to update of a loaddefs file. I mean a case of hidden dependency on a file that is the source for autoload declaration.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 May 2023 11:20:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 15 07:20:56 2023 Received: from localhost ([127.0.0.1]:42868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pyWG8-0001UV-90 for submit <at> debbugs.gnu.org; Mon, 15 May 2023 07:20:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pyWG3-0001RV-6W for 62762 <at> debbugs.gnu.org; Mon, 15 May 2023 07:20:54 -0400 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 <eliz@HIDDEN>) id 1pyWFw-0001wt-KT; Mon, 15 May 2023 07:20:44 -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=jVBdxos4b+F63Za1uKCIf2KBC7a0B7oWpeiOfpZFJ4I=; b=ju9DJUvREJU2 U292eK1U6nHJyczW0WYlD1mOae7RlFbXthpWlI9Q6Mf3+4cn5W72BcTGGjOtzTwh2i1xX3InNm12U oGbHMci7IU1Vv0owRTePnC0IUaotJxqaYHzREG4d1F8c4ZfCPzd3gEWCpz4xhaFewTcK+Sl4i/D0g udJJVJ30Ie6VuKnsc0wrr0t5O//al/SJyce8Smnpq6r5+/dxDYqV+rD/ROXcAT2RQm209gCksWQCA uqpoYRYhbMJimkw5QS3iTOyi54jqrvPvPmZPQmMkKu0NPBvOGSTl91Gho/dUz7V5aqPZrw4NRtY2R 8d/uwIglyNpqGOVLnHiZbw==; 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 <eliz@HIDDEN>) id 1pyWFe-0007lQ-I1; Mon, 15 May 2023 07:20:39 -0400 Date: Mon, 15 May 2023 14:20:29 +0300 Message-Id: <83mt25264i.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN> (message from Max Nikulin on Mon, 15 May 2023 17:11:25 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <jwvpm74i903.fsf-monnier+emacs@HIDDEN> <e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 15 May 2023 17:11:25 +0700 > Cc: Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > I see just one case when it may lead to incomplete > rebuild: a.el uses a function from al.el without (require 'al) and > autoload cookie is missed in al.el. This can happen when we use 'declare-function'.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 May 2023 10:11:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 15 06:11:36 2023 Received: from localhost ([127.0.0.1]:42818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pyVB1-0007k5-UF for submit <at> debbugs.gnu.org; Mon, 15 May 2023 06:11:36 -0400 Received: from mail-lf1-f42.google.com ([209.85.167.42]:49585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pyVAz-0007js-J5 for 62762 <at> debbugs.gnu.org; Mon, 15 May 2023 06:11:34 -0400 Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-4effb818c37so14507114e87.3 for <62762 <at> debbugs.gnu.org>; Mon, 15 May 2023 03:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684145487; x=1686737487; 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=VcGOfoKbjYK1uEao7GocKGjXtV7RGBsIK176uZPBi9k=; b=R64RvSPw1HHrqUFBlx/R58HEbrts6LSAMoRYOW+QvOgkvwZBBuFAT0pg/rnyrKUC1n 4nfPc5/eZv3QaHFHP+YU0K8Ck31vDT66jXgguw3wXCB42yxJ6tge9RaHOBhkoKu0qqP/ nkV/k2pQyYmeoFbLViN9KGtJ9WV6yve+wKHGbwhwaMiinFPr9IIKN8rroSbLsgYHQY9s ncIPu0W7T2GGWjxIWNjMS5xgyeGG70+Dz3v+WlSQG4raBVO8BLal0i82OVIzVc04KVFW Op0NE4k0VetPPBTygBvrj0CdYIld/imgc4h8QCzE1RuLktDAmpxhrTOvHNpkSGdinAg2 tQxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684145487; x=1686737487; 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=VcGOfoKbjYK1uEao7GocKGjXtV7RGBsIK176uZPBi9k=; b=CxY+XKG7BmsHAV3KneVnRBys9R3pv0kh7dDcmYTWorZN5AU4ds/9E/BrKpVLMvb7fT C20JOl4GK+fRBCwmAfIf2eiHPN8uAicaZU9I1qB//YbpGXHtIduOh8g04gd9LTp2MEj6 NGqVWRoli+2NVu6mRir1cnPZY+KfiwIasOn5xoPCoxKp3md9k/089V3d7aM7V7exZO3+ f9z2HeQmR2WfO6GDoj8kpzoJnjngaSANL/QTPse/3v7qr484ezZCjprvzjftz8xuH+OI o5zDvxRrwHx9oZ8jJBsbXCrnzbDifS4SZKFbif7/9xF0JIH+iaFY38WyCYj+Nq2BJ6L8 lMSQ== X-Gm-Message-State: AC+VfDy4XTfIFA6oJl8C0eswvlHDulzSUUubbkeBJ0xCZ+xudc5euzCM 3Dm9gJxTLjh+PckhiRsU3UI= X-Google-Smtp-Source: ACHHUZ6mTlXJnBR8zLUAyHR+sQXTGGvciKiELmGTMTmB0ztnh9p5ve229VegeF5gntBiNwcI+o9XvQ== X-Received: by 2002:a19:f009:0:b0:4f3:8244:95dc with SMTP id p9-20020a19f009000000b004f3824495dcmr860863lfc.15.1684145487142; Mon, 15 May 2023 03:11:27 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id j14-20020ac253ae000000b004ec508e3a9bsm2565600lfh.276.2023.05.15.03.11.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 03:11:26 -0700 (PDT) Message-ID: <e571126c-a249-35b5-f01b-a39ad5dd7d77@HIDDEN> Date: Mon, 15 May 2023 17:11:25 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <jwvpm74i903.fsf-monnier+emacs@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <jwvpm74i903.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 13/05/2023 21:48, Stefan Monnier wrote: >> 1. A script reads dependency files (if they exist) created during previous >> build and removes stale .elc files. > > `load-prefer-newer` should give us the same result already. No, because some .elc files may become stale not because of modification of the corresponding files, but due to update of a macro inside a `require'd file. Removing of outdated .elc files *before* byte-compilation pass ensures that no obsolete macro definitions are used. On 13/05/2023 21:49, Stefan Monnier wrote: >> Writing "stale" I mean more than comparison timestamps of a.el and >> a.elc. Dependency files may contain >> >> a.elc: a.el d.elc >> d.elc: d.el >> >> the script walks through dependency graph, compares timestamps and when it >> d.el is newer than d.elc, *both* "a.elc" and "d.elc" are removed. > > Make will already take care of this dependency and recompile `d.elc` > before `a.elc`. You are right when dependency graph is a tree. You provided an example of circular dependency in lisp/vc/ediff-util.el. It is the case when to correctly recompile ediff it is necessary to remove ediff*.elc files before compilation (I do not like your approach with breaking cycle at an arbitrary edge since outdated macro definition still may be used). Files necessary for byte compilation is another example of a dependency loop. I assume there are may be more tricky cases I am unaware about, so prefer to be at the safe side. Eli raised a question of rebuilding of an .elc file when a new dependency with outdated .elc file is introduced. Since it is almost impossible to get dependency list without byte compilation, there are 2 options: ask make to rebuild .elc files files once more (updated dependency graph is available during second byte compilation pass) or just remove all stale .elc file before starting byte compilation. I prefer the latter approach. Due to these reasons I prefer 2 stage incremental build. On 13/05/2023 22:43, Stefan Monnier wrote: > Not sure about two passes, but if you want it to be "right" (i.e. aim > to never need `make bootstrap`), then every `.elc` file will transitively > depend on every preloaded `.el` file, including `loaddefs.el` which is > itself auto-generated from all the `.el` files. IOW the only truly > "right" way is to always recompile all the `.elc` files whenever `.el` > (or `.c` or `.h`) file is modified 🙁 I still hope, it is possible to add loaddefs files as order-only dependencies. I see just one case when it may lead to incomplete rebuild: a.el uses a function from al.el without (require 'al) and autoload cookie is missed in al.el. After compilation of a.el dependency on al.elc is unknown thus updating al.el is not a reason to recompile a.elc. I hope, raising priority of "Warning: the following functions are not known to be defined:" to an error preventing creation of .elc file will solve the issue. Despite at first glance loaddefs ruin the idea with partial incremental rebuild and dependency tracking, it seems a workaround exists.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 13 May 2023 15:44:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 11:44:10 2023
Received: from localhost ([127.0.0.1]:39378 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pxrPm-0008HT-5r
for submit <at> debbugs.gnu.org; Sat, 13 May 2023 11:44:10 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11508)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pxrPk-0008HH-BZ
for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 11:44:08 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0D1521000BF;
Sat, 13 May 2023 11:44:03 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E14731000A3;
Sat, 13 May 2023 11:44:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683992641;
bh=QC2Tc5klewtDZCYeguZwpFfpeqf8zWEk7W8KhLhFJZc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=fahkM+Hmc2srgMxQalQ9jRgylo5gBWA3xC7s4ToZonpSsvy6asCQaaWwOqr+xpjlO
bFCv+9boQu2IFEUqN62wOzD5RlUxn/K2qd0Mw2Yb4/xPh7LOVsRVAum54/2LWe53cN
/O4FziTBH3aab6LqIlv8ZVrK+ZW9lch1WssUm9Le2f00kOa4xLRtm+Ll5WhD9R+2YA
NN1zBYPYzpoINKfF9aZsLM/OUzGLcAmnMTllEujhXw5DS/3SeTm2p9TTPRgEO+/KvT
jtp9wjIBO2RyewNhwfjy6jW5d38T//7a7rCkG65qZR00wJaqQV4HzvQiz/vQkby6Sg
Oks4V2JpPNtFg==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7CF471208BC;
Sat, 13 May 2023 11:44:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: circular dependencies in elisp files and make
In-Reply-To: <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> (Max Nikulin's
message of "Sat, 13 May 2023 14:34:06 +0700")
Message-ID: <jwvednki7iv.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN>
<831qjvjmw5.fsf@HIDDEN>
<48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN>
<83v8h7hxlj.fsf@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN>
<fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN>
<83y1lu505p.fsf@HIDDEN>
<9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN>
<83ttwhbn7b.fsf@HIDDEN>
<9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN>
<83sfc1bkt3.fsf@HIDDEN>
<cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN>
<83zg68afn9.fsf@HIDDEN>
<16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN>
Date: Sat, 13 May 2023 11:43:59 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.188 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> I do not see a reason for significant slow-down because I do not suggest two
> passes of *byte-compilataion*.
Not sure about two passes, but if you want it to be "right" (i.e. aim
to never need `make bootstrap`), then every `.elc` file will transitively
depend on every preloaded `.el` file, including `loaddefs.el` which is
itself auto-generated from all the `.el` files. IOW the only truly
"right" way is to always recompile all the `.elc` files whenever `.el`
(or `.c` or `.h`) file is modified :-(
So, in order to avoid this, we need to make concessions, such as
ignoring (transitive) dependencies on preloaded files, and those files
used by the byte compiler.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 13 May 2023 14:50:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 10:50:01 2023
Received: from localhost ([127.0.0.1]:39285 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pxqZN-0006kQ-72
for submit <at> debbugs.gnu.org; Sat, 13 May 2023 10:50:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32479)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pxqZL-0006kE-0T
for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 10:49:59 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ACF3A1000BF;
Sat, 13 May 2023 10:49:53 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B72621000A3;
Sat, 13 May 2023 10:49:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683989391;
bh=Imt7uXyQs8L7NnENecNpUpO6x2JpyGpwyi8KcWguwKU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=oKB0IsllXTOqtrNL3qiBMmhSXOml5YS+/PyjslkeQIJSqATanVGpJaBn/FmOXIwVW
EtkpqEvzmFNXvDpytI+0WfYt63NEoHnR/kdT/IduERfEWwMS0MSxv0gfG41OlqVvaL
dqYydGbTCcMZRpPOyDkqez0lH8r1YVJZ1jk6ewrte0qmhVBzD9+UHCOHXBAPq5fFjA
fr5bvEj760lpQVWtABmqmMjDhe4Xs8kuijqfQveGQeTpHrf5RsXfNhHHEUlRUMWUNQ
PYLy++bDAgeuUC2Lr1tSUCjK1MGCc2fTksT8pFwPb18n+uV3EB1aVO7bGrfpLOeEjP
yMhkDR3n+HHNw==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5456D12080A;
Sat, 13 May 2023 10:49:51 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: circular dependencies in elisp files and make
In-Reply-To: <b33b3dc4-728c-d94c-f665-51402ad3a0c4@HIDDEN> (Max Nikulin's
message of "Sat, 13 May 2023 18:21:56 +0700")
Message-ID: <jwvjzxci8xg.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN>
<fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN>
<83y1lu505p.fsf@HIDDEN>
<9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN>
<83ttwhbn7b.fsf@HIDDEN>
<9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN>
<83sfc1bkt3.fsf@HIDDEN>
<cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN>
<83zg68afn9.fsf@HIDDEN>
<16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN>
<83y1lsaaay.fsf@HIDDEN>
<63ccd7e3-f622-eef3-0ce4-4e7da4b92bb6@HIDDEN>
<83wn1ca46m.fsf@HIDDEN>
<b33b3dc4-728c-d94c-f665-51402ad3a0c4@HIDDEN>
Date: Sat, 13 May 2023 10:49:50 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.189 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Writing "stale" I mean more than comparison timestamps of a.el and
> a.elc. Dependency files may contain
>
> a.elc: a.el d.elc
> d.elc: d.el
>
> the script walks through dependency graph, compares timestamps and when it
> d.el is newer than d.elc, *both* "a.elc" and "d.elc" are removed.
Make will already take care of this dependency and recompile `d.elc`
before `a.elc`.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 13 May 2023 14:48:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 10:48:24 2023
Received: from localhost ([127.0.0.1]:39279 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pxqXn-0006h8-OH
for submit <at> debbugs.gnu.org; Sat, 13 May 2023 10:48:24 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43187)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pxqXl-0006gJ-Sp
for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 10:48:22 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0FD0A44084A;
Sat, 13 May 2023 10:48:16 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C8894440821;
Sat, 13 May 2023 10:48:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683989294;
bh=C2fRSoEtzyWVIxHp0hFQ2U8xwkIGdJkouSW8+BI6kMA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=fU+l34v5UW01ulf6vOUuejYVCd+0Me0amc2gerJmspYVSJRnczL7NLk7ZwT07bRzT
SfkZgXcL2SGpnJYY1GrK84nXbR0QBgDfn4Z9Xz647OpyUQ3dvMagXkgqZyAWhnSSU3
cjQKd/45ZIj3LHUKl551VDmC2UAH6/DXBZhSuatvAdXFgOANIxSXj7HlDZlCCoXCDg
0WB5LxEyE2EESPctwD4ejyy8Yi3H9iAlR/7TAvYfsD6d1jfskPHmaYn26DR6Mljujc
aDxXP4i1Q+VuVyufb1AkT0lngiTS8m6+QneVb9esqk4Ay/rorDfALjN8sxOD52zJ7y
A/UiFtJiUS2nA==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8A5E612086C;
Sat, 13 May 2023 10:48:14 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: circular dependencies in elisp files and make
In-Reply-To: <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> (Max Nikulin's
message of "Sat, 13 May 2023 14:34:06 +0700")
Message-ID: <jwvpm74i903.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN>
<831qjvjmw5.fsf@HIDDEN>
<48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN>
<83v8h7hxlj.fsf@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN>
<fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN>
<83y1lu505p.fsf@HIDDEN>
<9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN>
<83ttwhbn7b.fsf@HIDDEN>
<9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN>
<83sfc1bkt3.fsf@HIDDEN>
<cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN>
<83zg68afn9.fsf@HIDDEN>
<16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN>
Date: Sat, 13 May 2023 10:48:11 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.050 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 1. A script reads dependency files (if they exist) created during previous
> build and removes stale .elc files.
`load-prefer-newer` should give us the same result already.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 11:22:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 07:22:07 2023 Received: from localhost ([127.0.0.1]:36115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxnKB-0006B7-98 for submit <at> debbugs.gnu.org; Sat, 13 May 2023 07:22:07 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:49342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxnK8-0006AZ-I6 for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 07:22:05 -0400 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2ac8091351eso116472341fa.2 for <62762 <at> debbugs.gnu.org>; Sat, 13 May 2023 04:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683976918; x=1686568918; 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=H6dPX8Wtg92lwnmKXzaYLHr1bSGnuugqhZdF/YND4NM=; b=XvPdJYiJsxlNHBIwBInjcmNLf+puyBB8c2d8tmvrcWf7XyzJWirP42QfBqefNFMYm+ 2m6XtzsISR3JN72VRW3RmaOXNpetsJQs+FNtP3g0lYUscRurikbW8m6vtFubywFwqkaw AxAu7ZKPUqeRqzGN+cpqBoVRiojyUdJFdeAzp3mo1kLhoQNu45KpnHAZSlfufJWcVGsq uBo68osabYJAItBkrZemXymTOOYbsZ4uTj0xJCo2I7CgOnZSLNaIBQdqI66Yf1Kw510/ M0SQD5RVpmJZHsnD1zVm3MttrlJX0h8Y0MovLT1SeO3/rZ15PQP5ytmqhu4/atUoS8Ha IMEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683976918; x=1686568918; 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=H6dPX8Wtg92lwnmKXzaYLHr1bSGnuugqhZdF/YND4NM=; b=bK9yc3Ka37oAL5KonAgqtcBCXHfv8qmzqIkBqDq0+bz2Np6qRmkI3V1kjJMP4lZ/3p 1TsWVD0LQfsIxqIZkHRO6L5E8jUJriCAovXaZS9Mj7PY3/mSRfBF2/s7uhBWmNnmxifg 87WLRQDCWKFh2+iT7yrGbEVbh/AYn51/k4WM7IDqpZergmut0mKEAvARPCC0sDgdNhHk IcHA2MUzHTN5ZVyYxmP/7zsN9QNZxbZ0gsjpU/+nHSfqpRWA55ZpHUQJYVuYtyYhzMbk jo8UWxx3F8cDvDC597BqFtn1zKJ7A+Ur3G70cgXq8R7NEE9dh6/xMakkPvPCkFqiQRYS zFrg== X-Gm-Message-State: AC+VfDxi55P5gwHPGgX88Y1eWaOBRBpr/RteEW6910NBc5Yj6ZTaxyJA +8+AQPICQzAl5nCa3Fyk0qo= X-Google-Smtp-Source: ACHHUZ6aCHKWxzJFLV+7BaVxc7Inw+SMxW7HVcT08V/6s4so5AvMyQRO71Uw4MfDu4Ru/T+zfI/VDg== X-Received: by 2002:a2e:9a94:0:b0:2a8:ae90:83d6 with SMTP id p20-20020a2e9a94000000b002a8ae9083d6mr5131696lji.48.1683976918214; Sat, 13 May 2023 04:21:58 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id a14-20020a2e860e000000b002a8ecae9567sm3086478lji.84.2023.05.13.04.21.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 04:21:57 -0700 (PDT) Message-ID: <b33b3dc4-728c-d94c-f665-51402ad3a0c4@HIDDEN> Date: Sat, 13 May 2023 18:21:56 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <83y1lsaaay.fsf@HIDDEN> <63ccd7e3-f622-eef3-0ce4-4e7da4b92bb6@HIDDEN> <83wn1ca46m.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83wn1ca46m.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 13/05/2023 17:58, Eli Zaretskii wrote: >> Date: Sat, 13 May 2023 17:25:06 +0700 From: Max Nikulin >> >> On 13/05/2023 15:46, Eli Zaretskii wrote: >>>> Date: Sat, 13 May 2023 14:34:06 +0700 From: Max Nikulin >>>> >>>> 1. A script reads dependency files (if they exist) created during ----------^^^^^^^^^^^^^^^^^^^^^^^ >>>> previous build and removes stale .elc files. >>> >>> This will break if the updated files have different dependencies. You >>> need to recreate the dependencies each build. >> >> Let's consider a.el that contains (require 'd) or it autoloads some >> macro from d.el. If a.el changed then a.elc is removed on this stage, so >> updated a.elc will be created on the next stage. Dependency on d.elc is >> known from previous build, so if d.el is changed then both a.elc and >> d.elc are removed. If new (require 'd-new) is added to a.el then it is >> not a problem as well. a.elc is removed due to changed a.el. d-new.elc >> is either up to date or it is removed due to changes in its dependencies >> or in d-new.el. > > I was talking about dependencies, not about stale files. They will > need to be refreshed every build, because, unlike C sources, the *.el > files change in that aspect much more frequently. Writing "stale" I mean more than comparison timestamps of a.el and a.elc. Dependency files may contain a.elc: a.el d.elc d.elc: d.el the script walks through dependency graph, compares timestamps and when it d.el is newer than d.elc, *both* "a.elc" and "d.elc" are removed. It is unfortunate that a part of "make" should be implemented in the script, but I am unsure if some trick is suitable to leverage "make" power for removing of files instead of their creation. Next compile stage updates dependency files as a side effect and new dependencies may appear d.elc: d.el d-transitive.elc however absence of d-transitive.elc during dependency removing stage 1 does not lead to any problem.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 10:58:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 06:58:36 2023 Received: from localhost ([127.0.0.1]:36106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxmxP-0005cP-OH for submit <at> debbugs.gnu.org; Sat, 13 May 2023 06:58:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxmxN-0005cB-EM for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 06:58:34 -0400 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 <eliz@HIDDEN>) id 1pxmxG-0006go-Mk; Sat, 13 May 2023 06:58:26 -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=C41h+PoNz+GU5OPmO81rBvDbhVPpXbwo0afUWNZeeu8=; b=nu2u3nxonlmV mF2lNv27Zd+e5VgqEoXmvivZsKdwXxYJ5pf8Ho6JYfkS/qlHjqdNp7mSWFyBwi+1a7ChMSMS6zHRZ awKwT+D/fbpWk43gOcJ4UGyVZ+xXVncw5lRrnIOqFFgDK1dtzNIWOEmMApu2R4gADesgdqcswYH0j tFOU+LcpcCBaiZywK4yw1sP3WUdoFo2nLwj+ZN3YAJlNO36w8qVMfRMhYlQzfjo4FV5szoxDscTu1 4emFRpDArZ0tF0NT1LOv8vbc5DD7Ia9OftL4dllV1l/SBt8QQvSoV7PBd9ItRUimijsmtkqDR8E9r bUyJJfEqSzm4IaPHRFSfNQ==; 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 <eliz@HIDDEN>) id 1pxmxG-0006ev-5a; Sat, 13 May 2023 06:58:26 -0400 Date: Sat, 13 May 2023 13:58:25 +0300 Message-Id: <83wn1ca46m.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <63ccd7e3-f622-eef3-0ce4-4e7da4b92bb6@HIDDEN> (message from Max Nikulin on Sat, 13 May 2023 17:25:06 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <83y1lsaaay.fsf@HIDDEN> <63ccd7e3-f622-eef3-0ce4-4e7da4b92bb6@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 13 May 2023 17:25:06 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 13/05/2023 15:46, Eli Zaretskii wrote: > >> Date: Sat, 13 May 2023 14:34:06 +0700 From: Max Nikulin > >> > >> 1. A script reads dependency files (if they exist) created during > >> previous build and removes stale .elc files. > > > > This will break if the updated files have different dependencies. You > > need to recreate the dependencies each build. > > Let's consider a.el that contains (require 'd) or it autoloads some > macro from d.el. If a.el changed then a.elc is removed on this stage, so > updated a.elc will be created on the next stage. Dependency on d.elc is > known from previous build, so if d.el is changed then both a.elc and > d.elc are removed. If new (require 'd-new) is added to a.el then it is > not a problem as well. a.elc is removed due to changed a.el. d-new.elc > is either up to date or it is removed due to changes in its dependencies > or in d-new.el. I was talking about dependencies, not about stale files. They will need to be refreshed every build, because, unlike C sources, the *.el files change in that aspect much more frequently. > So no stale files should survive stage 1. The only issue with obsolete > dependencies is that compilation order may be not optimal. Stale files are already not an issue, because the build runs with load-prefer-newer set non-nil. > > Also, it is not clear what is the plan for the macros. If one of the > > macros used during byte compilation changes in incompatible ways, > > trying to byte-compile using Emacs which preloaded the previous > > (outdated) definition of the macro will fail. > > I hope, it is addressed above. It isn't. > > So some changes need > > also to generate a new Emacs binary, not just byte-compile in the > > right order. > > I expect that dependencies of the script removing stale files are > minimized. If changes in the breaks this script then it is time for > "make clean". If emacs binary depends on .elc files then some file may > be touched to let "make" know that the executable needs rebuild. I don't understand how this will work, but don't let me discourage you from trying to make it work and showing how. > > What is the plan for the various autoloads files? They depend on all > > the files, and many (all?) files depend on them. > > My plan is that autoloads/loaddefs are order-only dependencies for .elc > files. However autoloads/loaddefs files depends on all files necessary > to generate them. Same here. Thanks for working on this, anyway. If it can work, it could be an important change.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 10:25:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 06:25:21 2023 Received: from localhost ([127.0.0.1]:36041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxmRE-0004ej-L4 for submit <at> debbugs.gnu.org; Sat, 13 May 2023 06:25:21 -0400 Received: from mail-lj1-f176.google.com ([209.85.208.176]:44059) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxmR9-0004eP-RD for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 06:25:19 -0400 Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2ac826a1572so112422361fa.0 for <62762 <at> debbugs.gnu.org>; Sat, 13 May 2023 03:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683973510; x=1686565510; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=xU2tog0EHd6VOX3BDyc/hTQGekH4bv9CPfU6tErCZJQ=; b=Ig9wxF1kueXtRM1l+KcjBHNy3L9Y0wsGmYfR/2GRsP9whvUaPGwEv3d6xbch/wpuFq fVfoVfpSh0flU9VlYlmfFREP/0P4YAJAwfW2VgbHr5vJibNi2Lmhk1gybwbwBKYjS1YG 1YIQR+tGb37oXvdsth5zN9/0ic6zEmNexPFE/5Js2R8MVIDLJn+vDC99WYpdGJ8c2cI0 +1Jlqq6KAhotrXJqEDnIqU6c9biryX+JDdnsClc34/BFkl9UmZXkLnGR7wXH2D3mvCF5 LyhtOwHDbZRn27XCKzrXvGXartPQf/EF8sqJRvrqIDFMbuymh8Vcyb1DQDAepCstMSeJ QUkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683973510; x=1686565510; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xU2tog0EHd6VOX3BDyc/hTQGekH4bv9CPfU6tErCZJQ=; b=bxxvXHUBmeJgSc9Xqp3C5gZsybksx7ZQT7DeKHDRvpVl+16ApbLeovDZ7QdLPZiRYf zVamFuz95MOtu3N0TzCBhlafLXStM6Qrlyx4nI+PrPkgspQQs9OIO4k/I7uUxDDQTBun Tlb686fGZQbzxQX9+hXKhN5dQKLL1TcZSn6/MHk7JlsvAfxkHui4Kn53/kU8TL30HXxV zgGuhpB/nvuWLu3xLkJRcL3N6IMZw2v8zMNNuZIPpW2Uf2YaBUBXmJ7zRz51M3Sj/qII I7nQAFRyA6T3+vEShx29e9fDZUDoZfQtXO4frj4SzenWF6t86WBoTmP1Mi0tWcpTihp4 nkqQ== X-Gm-Message-State: AC+VfDxipfXpuAPDaugE4J7s6CLPmrKfGXW4wLTZhGsgQ/dYws4gc+v+ 4OXx1kX1qdjMPwBLx2aeSZw= X-Google-Smtp-Source: ACHHUZ5mtUhTKBBdtmr0oCqXPLSA0QPzECXR6unMlS7FBBIm8xBkjSpGxhFafpttsmEH2SCaNYvx3g== X-Received: by 2002:a2e:9605:0:b0:295:9be0:212b with SMTP id v5-20020a2e9605000000b002959be0212bmr5728817ljh.8.1683973509415; Sat, 13 May 2023 03:25:09 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id n15-20020a2e86cf000000b002ac833114besm1221898ljj.47.2023.05.13.03.25.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 03:25:08 -0700 (PDT) Message-ID: <63ccd7e3-f622-eef3-0ce4-4e7da4b92bb6@HIDDEN> Date: Sat, 13 May 2023 17:25:06 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> <83y1lsaaay.fsf@HIDDEN> Content-Language: en-US From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83y1lsaaay.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 13/05/2023 15:46, Eli Zaretskii wrote: >> Date: Sat, 13 May 2023 14:34:06 +0700 From: Max Nikulin >> >> 1. A script reads dependency files (if they exist) created during >> previous build and removes stale .elc files. > > This will break if the updated files have different dependencies. You > need to recreate the dependencies each build. Let's consider a.el that contains (require 'd) or it autoloads some macro from d.el. If a.el changed then a.elc is removed on this stage, so updated a.elc will be created on the next stage. Dependency on d.elc is known from previous build, so if d.el is changed then both a.elc and d.elc are removed. If new (require 'd-new) is added to a.el then it is not a problem as well. a.elc is removed due to changed a.el. d-new.elc is either up to date or it is removed due to changes in its dependencies or in d-new.el. So no stale files should survive stage 1. The only issue with obsolete dependencies is that compilation order may be not optimal. > Also, it is not clear what is the plan for the macros. If one of the > macros used during byte compilation changes in incompatible ways, > trying to byte-compile using Emacs which preloaded the previous > (outdated) definition of the macro will fail. I hope, it is addressed above. > So some changes need > also to generate a new Emacs binary, not just byte-compile in the > right order. I expect that dependencies of the script removing stale files are minimized. If changes in the breaks this script then it is time for "make clean". If emacs binary depends on .elc files then some file may be touched to let "make" know that the executable needs rebuild. >> 2. Normal "make" pass that takes into account dependency between files >> for ordering of compile commands. Dependency files are created or >> updated as a side-effect of compilation. >> >> Likely it is reasonable to split stage 2 into steps similar to current >> targets like main-first and mark most of files as dependent on a target >> that (throw its dependencies) compiles files required for byte compilation. > > What is the plan for the various autoloads files? They depend on all > the files, and many (all?) files depend on them. My plan is that autoloads/loaddefs are order-only dependencies for .elc files. However autoloads/loaddefs files depends on all files necessary to generate them.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 08:46:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 04:46:26 2023 Received: from localhost ([127.0.0.1]:35819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxktV-00052Y-V6 for submit <at> debbugs.gnu.org; Sat, 13 May 2023 04:46:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxktT-00052H-64 for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 04:46:23 -0400 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 <eliz@HIDDEN>) id 1pxktM-0003Cr-8x; Sat, 13 May 2023 04:46:16 -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=OoUk4CgqSHDfKSWYelpInGe9MMr2R5A5KWgwKr3yESg=; b=AVPDeXPb6Uf6 MpI9ZWPYYO9V5Z/jY9N9xomTJSSUZfK1NoS/6B62L1m8BqfL2ljc1hxsjC+sVrkPlrg+IJT9oJ1WM BEvLqg/IykxYKFLoDN1FGLEXManARaizm8WDy0sA8f0jXu4fiodgw4tpj6KG89OK8diCzoP3IUsS/ ZQ1PaiVYhORTRh9cwlPXuhucAscsFytZiaPy7Y9A92z7k7AnPUefrIX1/I+5I/M4JJtJQOWPftARb vLydeQeo+Wl0XQFe8kcGqlcC9hSz7fOUM+Xi2aF4l3AgCLSptQrMawump+lN5PBcLKPGGapQqbPds PsCYMfZ3Nf+JEMp243EHvw==; 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 <eliz@HIDDEN>) id 1pxktK-00076M-Sr; Sat, 13 May 2023 04:46:16 -0400 Date: Sat, 13 May 2023 11:46:13 +0300 Message-Id: <83y1lsaaay.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> (message from Max Nikulin on Sat, 13 May 2023 14:34:06 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 13 May 2023 14:34:06 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > 1. A script reads dependency files (if they exist) created during > previous build and removes stale .elc files. This will break if the updated files have different dependencies. You need to recreate the dependencies each build. Also, it is not clear what is the plan for the macros. If one of the macros used during byte compilation changes in incompatible ways, trying to byte-compile using Emacs which preloaded the previous (outdated) definition of the macro will fail. So some changes need also to generate a new Emacs binary, not just byte-compile in the right order. > 2. Normal "make" pass that takes into account dependency between files > for ordering of compile commands. Dependency files are created or > updated as a side-effect of compilation. > > Likely it is reasonable to split stage 2 into steps similar to current > targets like main-first and mark most of files as dependent on a target > that (throw its dependencies) compiles files required for byte compilation. What is the plan for the various autoloads files? They depend on all the files, and many (all?) files depend on them.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 07:34:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 03:34:17 2023 Received: from localhost ([127.0.0.1]:35669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxjlg-00034X-OC for submit <at> debbugs.gnu.org; Sat, 13 May 2023 03:34:17 -0400 Received: from mail-lj1-f178.google.com ([209.85.208.178]:48627) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxjlf-00034F-8o for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 03:34:15 -0400 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ac82b07eb3so110400351fa.1 for <62762 <at> debbugs.gnu.org>; Sat, 13 May 2023 00:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683963249; x=1686555249; 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=ApRcU211h3L8ZtBkw5eBWnnPSdc4s0QKFQrK75/WBsE=; b=k/dWQzjtBiU69ADoz702muHcAF69jaVic7rUuzzF0wapl3ssSh7Cuk8cymKkxX4qFn qhwvx905HBDLdREZNWF90mYcwocm4ZaWr+F6Oi6siuWvG936lLyQteGOGtw4VcCQxo30 kamdTPxvNCSSIpbIeK7muckDHuoHJ6mtsDjg90In1GfU2aSbEoiDX5UbyzVn3rKb0wpM G1HM/WSWcaywHSFCWJIlV34lcAm2/erb9ahVriJTHyg+j5FHLYugh0x8//OtW5o6oIuH t1SvlPMmY2lEKxUqzW5jeenPy3I6i+1XYCypI+EnoTFD3Ph9T4iTyuHYSHJaK3myBQcc Ij7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683963249; x=1686555249; 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=ApRcU211h3L8ZtBkw5eBWnnPSdc4s0QKFQrK75/WBsE=; b=JBZaxeVWS0LIBP03GQqtHmtX2b3qNGmlUMdXToFT/usBYqYexSHT4ythNKsUybGex6 Vmf5wJq+AX0CBbucL/BZBkxQB4Cqt/nTsGHSZp6BQ4G6SfylJVCfAYXkZt25UFynU0hI STURp2rsB8CnueGjvED80SSQo5280b6oERvuOSGjSrAWDkwzsI9uUaHGzXNbHV9x2Sqk WlRgHChj7vswaFx72RS6Hwsf1DszhYy/txdZLhJPycKk4GvSnBNcrWgl/a7b5nIpC0lc aDxit+iPkWuAP5k2IsjOGJQvWwZ8GKg/yyRKsahqXIqbCqhAhBYXgtxK0fQzZu44Rv4v obEA== X-Gm-Message-State: AC+VfDxkMLlidgqMLIncBHLijbjOUVtsuTvUdXPiYY8tTa5rfgIOO1ja QnqTx30X/IbRwhg9KoRHA0M= X-Google-Smtp-Source: ACHHUZ7ngRyxTBPk6lQdaT089oKCYvbYM3oa/XcC4hgpWOVR86XetR2XPn998X4p4/mxeriB6Cx9Lw== X-Received: by 2002:a2e:9d4c:0:b0:2ad:a213:269c with SMTP id y12-20020a2e9d4c000000b002ada213269cmr4058962ljj.5.1683963249038; Sat, 13 May 2023 00:34:09 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id v3-20020ac25583000000b004f143c11cbcsm1728160lfg.51.2023.05.13.00.34.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 00:34:08 -0700 (PDT) Message-ID: <16f3f59c-ce2c-2b0d-fe56-8a85b79a1b3f@HIDDEN> Date: Sat, 13 May 2023 14:34:06 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> <83zg68afn9.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83zg68afn9.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 13/05/2023 13:50, Eli Zaretskii wrote: >> Date: Sat, 13 May 2023 10:08:25 +0700 From: Max Nikulin >> >> ... What >> can be better is removing all stale .elc file before compiling of >> updates sources. A script iterates over dependency files and deletes >> .elc if any its prerequisite has been updated. Following compilation >> pass can safely use .elc files that are either survived from previous >> build as up to date or just refreshed. > > So you will make each build always do two byte-compilation passes > where today we have just one? And the first one of these will use > only *.el files, including for those that are preloaded into > bootstrap-emacs? Doesn't that sound like a significant slow-down of > the build? I do not see a reason for significant slow-down because I do not suggest two passes of *byte-compilataion*. 1. A script reads dependency files (if they exist) created during previous build and removes stale .elc files. 2. Normal "make" pass that takes into account dependency between files for ordering of compile commands. Dependency files are created or updated as a side-effect of compilation. Likely it is reasonable to split stage 2 into steps similar to current targets like main-first and mark most of files as dependent on a target that (throw its dependencies) compiles files required for byte compilation.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 06:51:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 13 02:51:03 2023 Received: from localhost ([127.0.0.1]:35560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxj5q-0001pP-RJ for submit <at> debbugs.gnu.org; Sat, 13 May 2023 02:51:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxj5o-0001oF-UI for 62762 <at> debbugs.gnu.org; Sat, 13 May 2023 02:51:01 -0400 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 <eliz@HIDDEN>) id 1pxj5i-0005dW-Tv; Sat, 13 May 2023 02:50:54 -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=FOW+D/TE7uI6HZAV23I6NTzSEKiqo3U03/0e0LFIeNA=; b=GdY+nDYG9v0R DOy2fcPpD+KHV82w3t2x8aJrT7VtFTzOsc2Yw04wtsKYJ6dqbqF3s+4pEbRtw7/+K3qjMnKiRCtuk KwIgIBZ0zkFkg/ONR1TQJPCAVagyd710nKk3z07crEy2Lbl/5aBT6U0c0mxsNme9anHhYR4I/NG2g NuxCWfJ3EfTKyRaubnxvkrQsNVJWPSqHgTr19lXlvaTqqVYb3Fw4oY3kkGy85HScFOIqxYfZM7wAK G4/4UqAbh5bq7LxmkxXSCivbR3n5KgAesh/9726+8lT8aldozw+fQyI8lOZq16CjRVq4qA0giUptL dOD6yIJ+G20wfl7gR0Ef3g==; 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 <eliz@HIDDEN>) id 1pxj5e-0005GS-Ue; Sat, 13 May 2023 02:50:52 -0400 Date: Sat, 13 May 2023 09:50:50 +0300 Message-Id: <83zg68afn9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> (message from Max Nikulin on Sat, 13 May 2023 10:08:25 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 13 May 2023 10:08:25 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > My initial idea was to compile files necessary for byte compilation at > first and for compilation of "regular" files load components required > for byte compilation and after that suppress loading of .elc files. What > can be better is removing all stale .elc file before compiling of > updates sources. A script iterates over dependency files and deletes > .elc if any its prerequisite has been updated. Following compilation > pass can safely use .elc files that are either survived from previous > build as up to date or just refreshed. So you will make each build always do two byte-compilation passes where today we have just one? And the first one of these will use only *.el files, including for those that are preloaded into bootstrap-emacs? Doesn't that sound like a significant slow-down of the build? Also, what about native-compilation, with or without AOT?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 May 2023 03:08:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 23:08:35 2023 Received: from localhost ([127.0.0.1]:34702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxfcZ-00014p-Dq for submit <at> debbugs.gnu.org; Fri, 12 May 2023 23:08:35 -0400 Received: from mail-lf1-f51.google.com ([209.85.167.51]:56334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxfcX-00014c-Qj for 62762 <at> debbugs.gnu.org; Fri, 12 May 2023 23:08:34 -0400 Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-4f13a72ff53so11958970e87.0 for <62762 <at> debbugs.gnu.org>; Fri, 12 May 2023 20:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683947308; x=1686539308; 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=FM7fbmFPdw4uJjj2uXFxi1LHW8PfgU0ecwraThaLXvg=; b=Z/BwH04HNWqXyWt15WhZ7ln9FhzFvyY0DG6uiBGx/qJ82xU7bg7T0Bt8w/R8Vsv5WT 2k0XI0AK2ammyH0II9fuJRthEWPsgAr6zgM3hlekb+w+6pB2QlsGMGwztX8rPJm1Tlue +F8spf28dHZbAx2MhXc+GWMx4g7CdYelg0MYCljfb8TzcqUt7lCqUxhoybSWi9JhYyAH +CeBWkogDrXyofq9KvFLJ+s/wTO2hCJu3jMYGxY/4s9CwCVj+oIvoOLxx4I551pa93ST EF8BiTRZGNlpN57bhIEn3+y821DJnKh1+M35YACxiRSkFI1xl7d6HScyvb+tfkeAR315 1S7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683947308; x=1686539308; 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=FM7fbmFPdw4uJjj2uXFxi1LHW8PfgU0ecwraThaLXvg=; b=VSlz1Re4NJSY8C3h/68CPxr8rue25I4pryK8xkSkI3xS5nYXG4Je4DlKKNNvcD56ow j0u3Kyf9Dzbr6657qJ7RmAQfdZxnFQFPEErDYTMtIP8gnOYu7zRaXujeOaWw3fUPTosN o1quUHyrKE0371L4dbfbT/8iu3TqZBQRJEjAwtzz/DieRszmRk5zdI8t0Sm2z8EW9IxF 5Kc7LLOafSGAp2g7G8eOYyZs2mHucq1IkFT082K2lbTtG8veq18y1G43HkP4K4Fgl5Zz P9csRGa7cij0Ztg8skYYwBIFaE/DppJ/veadUBDs+EoiycUUxuR48hj0O3poSeLnNt44 PmDA== X-Gm-Message-State: AC+VfDyGr4Sewu10XXn4gt9XBJ72JLTkMiWxC2i8526cg01ub6+u3X56 2AnA07Ljp9dOlW8cD/AZJu0= X-Google-Smtp-Source: ACHHUZ6a9qfK7MnJ4MqpLCE/MZ4EzaTEGusJ9XkwQwg64CtFSGt8jNOe7LrcGlV6pymU0ABNIGRKjQ== X-Received: by 2002:a05:6512:3c9:b0:4ed:c64c:37b with SMTP id w9-20020a05651203c900b004edc64c037bmr3859121lfp.62.1683947307451; Fri, 12 May 2023 20:08:27 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id m25-20020ac24259000000b004f13ca69dc8sm1673141lfl.72.2023.05.12.20.08.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 20:08:27 -0700 (PDT) Message-ID: <cfe1d311-ad56-c37e-a54f-0d86c9006f37@HIDDEN> Date: Sat, 13 May 2023 10:08:25 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> <83sfc1bkt3.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83sfc1bkt3.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) On 12/05/2023 23:01, Eli Zaretskii wrote: >> Date: Fri, 12 May 2023 22:26:47 +0700 From: Max Nikulin >> >> I expect that >> >> emacs -Q --batch -l bytecomp --eval \ >> "(mapc (lambda (x) (princ (car x) (terpri))) load-history)" >> >> gives reasonable approximation to "files necessary to load bytecomp". >> What should be added to prerequisites besides bytecomp dependencies? > > Anything that bytecomp loads via autoloads while compiling. Also > byte-opt and its autoloads, I think. You are right concerning autoloads, while byte-opt is just one extra file in the dependency list. However the same expression evaluated when `batch-byte-compile' call finished gives list of dependencies for the just created .elc files. Basic statistics based on dependency files may provide better approximation which files should be compiled at first to achieve faster build. I do not think that complications you described are blockers for accurate dependency tracking. My initial idea was to compile files necessary for byte compilation at first and for compilation of "regular" files load components required for byte compilation and after that suppress loading of .elc files. What can be better is removing all stale .elc file before compiling of updates sources. A script iterates over dependency files and deletes .elc if any its prerequisite has been updated. Following compilation pass can safely use .elc files that are either survived from previous build as up to date or just refreshed.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 May 2023 16:02:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 12:02:02 2023 Received: from localhost ([127.0.0.1]:60633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxVDW-0006fN-7e for submit <at> debbugs.gnu.org; Fri, 12 May 2023 12:02:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxVDQ-0006el-84 for 62762 <at> debbugs.gnu.org; Fri, 12 May 2023 12:02:01 -0400 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 <eliz@HIDDEN>) id 1pxVDH-0002VT-Ot; Fri, 12 May 2023 12:01:47 -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=4Cybdk2qePALyUgQ+oT6INWOn2hiy4y+q0ckGbZDVn0=; b=khJsg9f4P94p JvlEKbhl1gVSJC3yWQoq7mTzKCwzcdu8+T2uCDfyH31EZN3ckzMM2mga+OLCXO36ftJHX79BsVTDA KFquuhSlHwiUM8twgClOWoCJpZBzQaIFTbg+aD10SPS0UHUE/iJmNzq7d43JGbFenkhzMO4GtjkcH vETrHGBI06u9gFzhk80bnrGJG9cK48N4898AltI6D4j+DyVTEOWvzj3t6IaaORtF4GRV8zqFwbhDn 3D0QwdZX7rkRuGDzmB89R4iEilCYcdWfDrLmC5+6Csa000Ghqx8GpFMHAhVgPTO7Bpa0j8p9tTz9k vPtbwXihdk+6tnWEpyz50Q==; 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 <eliz@HIDDEN>) id 1pxVDH-0001pT-1V; Fri, 12 May 2023 12:01:47 -0400 Date: Fri, 12 May 2023 19:01:44 +0300 Message-Id: <83sfc1bkt3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> (message from Max Nikulin on Fri, 12 May 2023 22:26:47 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 12 May 2023 22:26:47 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 12/05/2023 22:10, Eli Zaretskii wrote: > >> > > Why only bytecomp? Byte compiling needs more than just bytecomp, > > AFAIU. > > Because the ".el.elc:" rule uses "-f batch-byte-compile". I expect that > > emacs -Q --batch -l bytecomp --eval \ > "(mapc (lambda (x) (princ (car x) (terpri))) load-history)" > > gives reasonable approximation to "files necessary to load bytecomp". > What should be added to prerequisites besides bytecomp dependencies? Anything that bytecomp loads via autoloads while compiling. Also byte-opt and its autoloads, I think.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 May 2023 15:26:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 11:26:57 2023 Received: from localhost ([127.0.0.1]:60457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxUfZ-0005TD-Bw for submit <at> debbugs.gnu.org; Fri, 12 May 2023 11:26:57 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]:47368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxUfX-0005Sz-95 for 62762 <at> debbugs.gnu.org; Fri, 12 May 2023 11:26:56 -0400 Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-4f13dafd5dcso11293549e87.3 for <62762 <at> debbugs.gnu.org>; Fri, 12 May 2023 08:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683905209; x=1686497209; 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=am/+m7dJge0H4cdoOhNBdG4WJC3MvyTK/Ur9D9/COw0=; b=HBZmUi39btnujv1rDQXrXqDbLYyMUlQPohpsQjk4ipTxpJKGdVWCDTsdXA/fQU7gwN TuaCEHNaSqtGtM09foHP6hcniSh0Dz/dCZXb7fBkZHhCm1q6ytLGnbEWoF6CYiHfZbXJ J/5yMB/eZnX656hLW04BCdDdcOU2uQ6guU0Dx/HHwk3y7TI41uN4rujBxBM58BLhzYMs P0Hjfi3kh78B829CmqJFqOMGM5Hcaug+eix1MwP0GQbyCvxv/z44oZjEIdYzLDCyia64 /sjrrpT1c4SdhXD/QL6PBVs1p9FtKldkYZyzJsVv+6AyUF59pyIgkKGhfBEXHpvz31QR 8iEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683905209; x=1686497209; 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=am/+m7dJge0H4cdoOhNBdG4WJC3MvyTK/Ur9D9/COw0=; b=AxyrNIpr0esqxGul5ljRk/U12PiNLZ+giOCW6Ycr+2tqjXmy43S3RyzVyJl+xqf179 HIsPgKThDEweIkupiGCsF422i5Q5qJqOYws2o7TTgK6668cOyefmzZwoavnJB9IUEpG2 jw0onFFnYLh83135LRr/8Fa7SyCsW2qSmqE89OMcNJAhJyDIjbWQJ7o0amuMMFplim2W SVC9b0mE6Vmph/OEXK94eNQbMUHhql9rZT3EK8gadfxIWL/brkquq/KzXLk0YjlzGk8s 1T/2dPllslfGjRhJUTqZ6kDvWykEOjWKi+VpIe4AFO8CIdO/X0WrbGM4kU/Q5/mZagvK KKcw== X-Gm-Message-State: AC+VfDx8uQBKccheSj1+oKgMCuwe048kXgYSsWAMgf5zTJnMznhUyVXy xmXoEd8zl4rmyPHKmBT9E/w= X-Google-Smtp-Source: ACHHUZ6D/235hwueQXEo3kQo6X8MwjiGL5MWB7cNFs2kVDd8b2kxJTsmlwRI68zaGk3Jnj4BWBXzAQ== X-Received: by 2002:ac2:4d02:0:b0:4f1:3e97:4486 with SMTP id r2-20020ac24d02000000b004f13e974486mr3957210lfi.57.1683905209188; Fri, 12 May 2023 08:26:49 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id t16-20020ac25490000000b004f25c13ea67sm1338662lfk.97.2023.05.12.08.26.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 08:26:48 -0700 (PDT) Message-ID: <9aa7edb6-c6c4-39ad-4302-371e5e58b4f6@HIDDEN> Date: Fri, 12 May 2023 22:26:47 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> <83ttwhbn7b.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83ttwhbn7b.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 12/05/2023 22:10, Eli Zaretskii wrote: >> Date: Fri, 12 May 2023 21:59:56 +0700 From: Max Nikulin >> >> 2. At first, files necessary to load bytecomp are rebuilt > > Why only bytecomp? Byte compiling needs more than just bytecomp, > AFAIU. Because the ".el.elc:" rule uses "-f batch-byte-compile". I expect that emacs -Q --batch -l bytecomp --eval \ "(mapc (lambda (x) (princ (car x) (terpri))) load-history)" gives reasonable approximation to "files necessary to load bytecomp". What should be added to prerequisites besides bytecomp dependencies?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 May 2023 15:10:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 11:10:13 2023 Received: from localhost ([127.0.0.1]:60386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxUPM-00053S-JS for submit <at> debbugs.gnu.org; Fri, 12 May 2023 11:10:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxUPK-00053C-TT for 62762 <at> debbugs.gnu.org; Fri, 12 May 2023 11:10:11 -0400 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 <eliz@HIDDEN>) id 1pxUPD-0001sQ-Ti; Fri, 12 May 2023 11:10:03 -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=WpN6ylvG/QR8TBFv4wfBLHJ/ojmQ3sL20VmuNmR7nV0=; b=ADdZOg8OolLi 5KAklWkS0e0cVuz7MiJqRVUbhrypGEBzAyNONfYhTG5hbcDTbnKdxbm4SHI7RQmwYJZeXJXeewRsH oSMfnpD+dfN3VrKKfrojBb0Dz7Wm3RUEwKGPfmqL0tpQHzoJWl6laqP+izfBy2DDLxBg66Cp1Up+i MnJD9FS0mGOTpo+fuUXK0e0zeetKwBbgzoukUOpYYfC/+7sG8qbgnCnehp/OcYhmbc89bkY3b+hWt Sviw7el7W0CVAJlPZBmZqq8+caUUKzJdDn/NlKnTP4ptETwKMJTqiOdPmTQqkD+lRv9vr+xwrND7N JETNBZSN4qYNrBSolvZy3A==; 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 <eliz@HIDDEN>) id 1pxUPC-00032j-Lo; Fri, 12 May 2023 11:10:03 -0400 Date: Fri, 12 May 2023 18:10:00 +0300 Message-Id: <83ttwhbn7b.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> (message from Max Nikulin on Fri, 12 May 2023 21:59:56 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 12 May 2023 21:59:56 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 11/05/2023 22:59, Eli Zaretskii wrote: > >> Date: Thu, 11 May 2023 22:14:03 +0700 From: Max Nikulin > >> > >> My idea was to suppress loading of .elc files during compilation of > >> such files. > > > > That idea will make a typical build much slower, for the rare case > > where such measures are really needed. That's the wrong balance in my > > book. > > I have noticed that you are afraid that correct rebuild might be too > slow, but I do not see a reason why it should be noticeable. > > 1. There is no need to suppress .elc during initial clean build that > takes enough time. It is for incremental build when usually only a > fraction of all lisp files are recompiled I think it will be much more than "a fraction", due to dependencies. But I will withhold my judgment until I see the actual code and what it does to the build. > 2. At first, files necessary to load bytecomp are rebuilt Why only bytecomp? Byte compiling needs more than just bytecomp, AFAIU.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 May 2023 15:00:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 11:00:08 2023 Received: from localhost ([127.0.0.1]:60305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxUFc-0004nW-9N for submit <at> debbugs.gnu.org; Fri, 12 May 2023 11:00:08 -0400 Received: from mail-lj1-f179.google.com ([209.85.208.179]:61497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pxUFZ-0004mR-IO for 62762 <at> debbugs.gnu.org; Fri, 12 May 2023 11:00:06 -0400 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2ac8c0fbb16so95495301fa.2 for <62762 <at> debbugs.gnu.org>; Fri, 12 May 2023 08:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683903599; x=1686495599; 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=SK0lAq/BggcEMCzEqSfCQcCnB+EgPNyflQ2Us35WOA8=; b=GNvKbWq/WZ4LEE4PPYiaxhGanuQiabHLdArStsvCGTx8XNsduWJh/hXW6ieH8QIjVH RV40qoYh9urqZX683m+nfnX399MvN5VIq9aL5TxOsCRkd7OOgWak4mbS28dZe1smn94P /DuWHu4A9HyNoBc1PFf03+1OGYOMGM4PCldb72oTNOfDcm0agHHve3bAzmCez9b51eCy Fjf/zhkVFvWOpp/Uh+sooEfTCXU8BXBZg4+RczfaFN/EJENPM/uRVDHnBSft25LNvJfJ Batyj33+FuxT960Wf6Kb0+1F+cgcR67SR1Pk61wEgj6EqA+YaxdBdhEYqE/6N3hZLWY8 jjlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683903599; x=1686495599; 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=SK0lAq/BggcEMCzEqSfCQcCnB+EgPNyflQ2Us35WOA8=; b=kRxBV9gR0Xdu57mTkEXMH4zEW+45VWn81/Pv2WI/V4sY8rTVX+ez4G3Yv1oe9g1YFa /wHTmK6gzZzrZA66+Cv0hf3EeW2jD7AOjbvQS0BVJn3cMhyXhyaaFzRGij4/XdfLgMu2 w3igj5E6OkD195kSWuHbaXovjfUiv6LYvH99x6MpvN3taC2+d7YwZw9+KrHAGiRmDK1e h5BExJ0MSMF56WStPiA7bpJLB7+1+TlmoaUbcj207z5rHTE6BcfvQbbeOhWl7rIDE7Gh e4WrHKSJ07lxD+qoC/W1rtXx8N5hhihoaDhzfiL6MbIYt2YBip2qaMcoerMgqWGghqNa sVFA== X-Gm-Message-State: AC+VfDzVYHBF0skxOKnlQ/1Var2zRGeVZ5E+b5xBl0WFoqrxwC+JGCRr TLuuvdx9TJ8i+jC148yf7fg= X-Google-Smtp-Source: ACHHUZ6smOoJwXT6rixRWTQfLgYfFIip8qwSbcF4UzTsTuHK3nZ/QUsOzJtPaADpYsH3x4BZOnBZuw== X-Received: by 2002:a2e:80cd:0:b0:2ad:8c4a:ef7e with SMTP id r13-20020a2e80cd000000b002ad8c4aef7emr5021749ljg.43.1683903599013; Fri, 12 May 2023 07:59:59 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id z18-20020a2e9b92000000b002ada45ce1fbsm1488255lji.128.2023.05.12.07.59.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 07:59:58 -0700 (PDT) Message-ID: <9d8db5af-1917-1d0a-0360-ac122e137a53@HIDDEN> Date: Fri, 12 May 2023 21:59:56 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: circular dependencies in elisp files and make Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> <83y1lu505p.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83y1lu505p.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 11/05/2023 22:59, Eli Zaretskii wrote: >> Date: Thu, 11 May 2023 22:14:03 +0700 From: Max Nikulin >> >> My idea was to suppress loading of .elc files during compilation of >> such files. > > That idea will make a typical build much slower, for the rare case > where such measures are really needed. That's the wrong balance in my > book. I have noticed that you are afraid that correct rebuild might be too slow, but I do not see a reason why it should be noticeable. 1. There is no need to suppress .elc during initial clean build that takes enough time. It is for incremental build when usually only a fraction of all lisp files are recompiled 2. At first, files necessary to load bytecomp are rebuilt, so during compiling majority of files, suffix list is modified immediately before `byte-compile-file' call. That is why only files required by source file of the current target are affected. 3. I hope, it is possible to suppress loading of .elc only in the case of circular dependencies.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 May 2023 15:58:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 11 11:58:47 2023 Received: from localhost ([127.0.0.1]:53197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1px8gp-0005CT-6h for submit <at> debbugs.gnu.org; Thu, 11 May 2023 11:58:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1px8gn-0005CF-MG for 62762 <at> debbugs.gnu.org; Thu, 11 May 2023 11:58:46 -0400 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 <eliz@HIDDEN>) id 1px8gh-0005xu-3J; Thu, 11 May 2023 11:58:39 -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=WnScCTx9/XOODjzhym4qSns1mhguy6zKvU5lw3pn3sM=; b=QoApRy2wqdMu T90aRWzBLdwZvp2NmpBfI8LWEW1kIuECrKIo8DTK48F23xePttDfP/tw+SPi+TnUVGlr0JRscBHHi QMGoDzWEAtUTbOqlrFc91j8fCGOGc9Nva15QLxTRjoOZYhR0GTNGeeuKumSqhwqRK0j0q7gnuvpfL e0gkCWJKq5rYxEntJv3P7SlxMkHJIYgmiuGjB6O2PzUBAcvh9aZLIrar8EST4th+kOdllS7qUfyOE R4kP8s04Bz1hBPLTIf0cFPgXKF7Hfxb28oPh6auJG/n3vYZ03uNkLzL7VkLzvEW7KU0HnkMJmqyV1 zJICOTu0stY8cDAKHnHCxA==; 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 <eliz@HIDDEN>) id 1px8gg-0001d7-5P; Thu, 11 May 2023 11:58:38 -0400 Date: Thu, 11 May 2023 18:59:46 +0300 Message-Id: <83y1lu505p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> (message from Max Nikulin on Thu, 11 May 2023 22:14:03 +0700) Subject: Re: circular dependencies in elisp files and make References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Thu, 11 May 2023 22:14:03 +0700 > Cc: yantar92@HIDDEN, bzg@HIDDEN, dmitry@HIDDEN, > 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > My idea was to suppress loading of .elc files during compilation of > such files. That idea will make a typical build much slower, for the rare case where such measures are really needed. That's the wrong balance in my book.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 11 May 2023 15:20:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 11 11:20:33 2023
Received: from localhost ([127.0.0.1]:53152 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1px85o-0003zm-SY
for submit <at> debbugs.gnu.org; Thu, 11 May 2023 11:20:33 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56060)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1px85m-0003zX-LI
for 62762 <at> debbugs.gnu.org; Thu, 11 May 2023 11:20:31 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B8F380148;
Thu, 11 May 2023 11:20:25 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A886180677;
Thu, 11 May 2023 11:20:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683818423;
bh=wOxbRr0uTvmvqGI1KRnylurzVr8nHABVpDn3ybE0k0Q=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=E+7B9aGwx5iFaGiE3PnA8K4+OzimfimiXt0AzmAcjMGw5eC5pTnWQwJ7k7zIGkT6R
eZMIbD4sSvwqj+szJzyvKt6FjGA3uP0Z+Cp4LwjLb352iEuImobn/l2MNtqE6CfETv
z3Hnb/Vrunfrlld4O2a4Jc9LXUE9TwPDRR1pJdxHT8q6VD9Sbi4ALEwc8xw5Cs1h5I
kLVLu0JyKkp+dpa/LtPPB1PpbzR+K/IbibaOjFkkgSWwOWa9vB6a0kk1GiNQhHY5Sl
TpFHBxYKATDsiiR/B2eZj/j1V9OxvzIhm3F9rfamLu/VS0DfVvYc67BC8IYFFMHXKv
H5ScYuQfL9WxQ==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 81E46120197;
Thu, 11 May 2023 11:20:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: circular dependencies in elisp files and make
In-Reply-To: <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> (Max Nikulin's
message of "Thu, 11 May 2023 22:14:03 +0700")
Message-ID: <jwvh6sioq0q.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN>
<831qjvjmw5.fsf@HIDDEN>
<48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN>
<83v8h7hxlj.fsf@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN>
<fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN>
Date: Thu, 11 May 2023 11:20:14 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.011 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> important. Do you mean the following
> lisp/vc/ediff-util.el:(provide 'ediff-util) ;FIXME: Break cyclic
> dependencies and move to the end!
Sounds about right, yes.
> and mutual `require' 'ediff-util from ediff-init.el and 'ediff-init from
> ediff-util.el? My idea was to suppress loading of .elc files during
> compilation of such files.
When I looked at it, my approach was to break the cycle in an arbitrary
way and say that if it occasionally leads to a miscompilation it's the
package's fault.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 May 2023 15:14:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 11 11:14:14 2023 Received: from localhost ([127.0.0.1]:53147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1px7zi-0003pA-0M for submit <at> debbugs.gnu.org; Thu, 11 May 2023 11:14:14 -0400 Received: from mail-lf1-f54.google.com ([209.85.167.54]:62865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1px7zg-0003ot-Ja for 62762 <at> debbugs.gnu.org; Thu, 11 May 2023 11:14:13 -0400 Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-4f00d41df22so47823404e87.1 for <62762 <at> debbugs.gnu.org>; Thu, 11 May 2023 08:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683818046; x=1686410046; 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=NbSp3umIc0ASAG2/CpQY5gM0Ya/ov5d7mKqaCf0Difo=; b=j0MeVWhyOqxzOjuJEENTQubJRtcX+gFLaRxVrqzZe3mNgbZSyC4eX7Qm97dG8qIniN 2amEhVadLetUKJIg9VWDpKRLQgEesteoGcMupmFT03tjjxcXDi0H6h1g/YS3KE4rWn/P 8OB0epQXiqYGmSvF8MaMmzUJqzpik9iHTaXHIkYCysGQom/jKnaFwXi4AupICMGqfv0D HJ8mT9FPTWwozfUkLPckFiW08HU7ZL5vFK+R0sp4bLGFKFSnQlGyseOsnwUeC7emoAO+ MLFmJIzHGl175vaVGhdM7/tf2l7RmIwT9HhbX6M5kldNuWf8LJCHyZZTYkX47QkAdT6g NxUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683818046; x=1686410046; 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=NbSp3umIc0ASAG2/CpQY5gM0Ya/ov5d7mKqaCf0Difo=; b=R4f4RNlWgyHDC9gKeM+Lt7dWW1KQZwx+NdgylIsqxm/a6q4nyoQTTCsZ15ENdjOuFy 55Wf4fAynU+4ORVfh1/bX8OTbadZPUv12hhsoK92wkRxU44tCJ285TMBVZ44Uc1086hK Qa+f56OXVh3CK9687fsmFn8xrfHCX0DLCb5+87qetVXqlOyQMm1vmxYxOJ9QI86iLW7T P4rohbqgQ86WA7vD5obm1jl9aRzXMJt8h0pXP26ZyGfuHiD3TQlkc9rru1N5xB77tmyY 35EV7XDMBmWh+bmhn5BJGjjWnVSywf5II6Pq2b3ZTz3vWzVwyq+BoMTY6/rafme5SQsS r7SQ== X-Gm-Message-State: AC+VfDzIvbJPevVHNIYXxer8U/Ri0yfGmB9ZXA70Kw8rRzXOMGEUy4ID RijMJahplqtNuK4GaZ5MDEo= X-Google-Smtp-Source: ACHHUZ7hkYN6tLrIreG9YX0zjdD9/xUp2pfipdqpD1984ZRE0Ai8EH+4Xr9p4OW8xc/2Wz8j6MonzA== X-Received: by 2002:ac2:414e:0:b0:4ed:bb8c:5058 with SMTP id c14-20020ac2414e000000b004edbb8c5058mr2206966lfi.6.1683818046185; Thu, 11 May 2023 08:14:06 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id n7-20020ac242c7000000b004f1d884a4efsm1133044lfl.242.2023.05.11.08.14.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 08:14:05 -0700 (PDT) Message-ID: <fb3cbf7c-2df6-5102-4b00-6e46f2373596@HIDDEN> Date: Thu, 11 May 2023 22:14:03 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: circular dependencies in elisp files and make Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> <831qjuisa4.fsf@HIDDEN> <jwvednueixo.fsf-monnier+emacs@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <jwvednueixo.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 06/05/2023 01:26, Stefan Monnier wrote: >> If you want to find them, you will have to write the code to detect >> those dependencies, and then look at the graph produced from them. >> There's no other way (unless Stefan happens to remember some by >> heart, by some luck). > I think looking for calls to `provide` that are not at the end of files > is a good first step to finding the obvious ones (if my memory serves, > viper and ediff are two examples in Emacs's own code. I see no cyclic dependency in viper, at least based on `require': viper.elc: viper-init.elc viper-keym.elc viper-cmd.elc viper-cmd.elc: viper-util.elc viper-keym.elc viper-mous.elc viper-macs.elc viper-ex.elc viper-macs.elc: viper-mous.elc viper-ex.elc viper-util.elc viper-keym.elc viper-ex.elc: viper-keym.elc viper-util.elc viper-keym.elc: viper-util.elc viper-mous.elc: viper-util.elc viper-util.elc: viper-init.elc I expect that it should ensure ordering for make allowing parallel execution to some degree. Frankly speaking, I have not realized why `provide' not at the end is important. Do you mean the following lisp/vc/ediff-util.el:(provide 'ediff-util) ;FIXME: Break cyclic dependencies and move to the end! and mutual `require' 'ediff-util from ediff-init.el and 'ediff-init from ediff-util.el? My idea was to suppress loading of .elc files during compilation of such files.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 10 May 2023 14:52:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 10 10:52:59 2023 Received: from localhost ([127.0.0.1]:48635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pwlBa-0000A5-Mo for submit <at> debbugs.gnu.org; Wed, 10 May 2023 10:52:58 -0400 Received: from mail-lf1-f51.google.com ([209.85.167.51]:55297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pwlBX-00009p-9c for 62762 <at> debbugs.gnu.org; Wed, 10 May 2023 10:52:57 -0400 Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-4f1fe1208a4so5311048e87.2 for <62762 <at> debbugs.gnu.org>; Wed, 10 May 2023 07:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683730369; x=1686322369; 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=U9Ej4FxPtnBJTLkyqoMH+A929Fygr8QKOUKY6EezfqQ=; b=q4y+X9ehseyHJjd6XSFcMuZ/nVWS7MI8sd9WkX+Rh7CsGt41IdZraKfeT3DbBvy+U6 vE1/Wz3zkqf0PGhB9ZWDijE4s5IaUBgCC+4BqxnU6CL3X0VnmwbNApN7iVYGealcCg8c PecW2RiUliEzBq+XsYFr0JAC1aALzq0KemHsHPbnqtDMmBCi6M/xzO9ps5TIUv4ukfwL ja89q6JXM8WJM//JOA0ICcJOm3eB3/XXEiBeI7G6v5mhmR4t5BPoMA+2zTjtOrjh7jnF lcSHIZENGbC217YcLWuygabMry1mcdF1HpCHkyG18EUGuuWO8UiqsvaN5SR7rwwGotvb bv4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683730369; x=1686322369; 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=U9Ej4FxPtnBJTLkyqoMH+A929Fygr8QKOUKY6EezfqQ=; b=H5rIBSk5ryTYN7qGMVjR7oHEGvhDEErtNDgO0wlOkOq0av6KprWKR8ReUzxYexN+cG iQhcpdWYuljL+taDZaJhZ/s4K6udVPJQ6Y1+n3Lvz+/2Qk0p1b708CnbZdBR583O8dB4 s/QuRyPBgy6tad3FKDJgWC6wqJOygrR8bCFwxp6ICgej0C6QErbpWo7c44hM6MIc1KHw /O4NaC1tmWS2X2l7Fw9H4BLKC4rZ3eyzmjn1SnqoeigWaxfNtCCoZKw0uFpoSeNv616n PLgacnHkImvNSDMO6LtGacLy7c6qJFKU7K+VANS3U44F2o2xFs4dw+xayibwMb/59rtE VbvA== X-Gm-Message-State: AC+VfDzvY272kSLSeP+GfEEEdbNzfGgJhyJ5l5xVJ+tgSv1nW0cqeds+ ZtILG9brJ6quejzjZp/KBTc= X-Google-Smtp-Source: ACHHUZ4ZNBfxV67bLmcVdsEtJlQDJZGpBFeIW6EhCFQ1rPUPqO+AGXXKvFDGJbLTCQFFuFSGQypb6A== X-Received: by 2002:ac2:5deb:0:b0:4f1:1de7:1aac with SMTP id z11-20020ac25deb000000b004f11de71aacmr2146251lfq.20.1683730368857; Wed, 10 May 2023 07:52:48 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id c2-20020a197602000000b004d023090504sm756395lff.84.2023.05.10.07.52.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 07:52:48 -0700 (PDT) Message-ID: <2e6ea8c1-19fb-298a-1336-27b09925d8a0@HIDDEN> Date: Wed, 10 May 2023 21:52:46 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Ihor Radchenko <yantar92@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> <875y93kujy.fsf@localhost> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <875y93kujy.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 08/05/2023 17:05, Ihor Radchenko wrote: > Max Nikulin writes: >> (defun tst-assert-load-dir () >> (let ((dir (tst-get-load-dir)) >> (url "https://orgmode.org/worg/org-faq.html#mixed-install")) >> (unless (equal tst-load-dir dir) >> (error "Path shadowing detected, see <%s>. %s vs %s" >> url dir tst-load-dir)))) > > I think we can try to do the following: > > 1. Use the load-dir test, warn, and try to re-load > 2. Use org-assert-version, but downgrade error to simple warning Ihor, final decision is up to you. I think, `org-reload' may be recommended in a warning message. I am unsure if `org-reload' called from the assertion while an Org component is loaded may not cause a more severe issue. My special concern is reloading when new Org is being compiled: is it safe or reloading should be suppressed completely? I believe, during creation of .elc files, assert macro should signal an error since a warning is not enough to prevent loading mixed compilation result to next Emacs session. I do not like that currently during compiling with old Org loaded, `org-assert-version' causes just a warning. Users have difficulties with clean recompiling. While loading, non-fatal error may be a better option when versions do not differ too much. I like that you are not going to throw version check away completely.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 8 May 2023 10:02:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 08 06:02:00 2023 Received: from localhost ([127.0.0.1]:39229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pvxgu-0004XS-36 for submit <at> debbugs.gnu.org; Mon, 08 May 2023 06:02:00 -0400 Received: from mout02.posteo.de ([185.67.36.66]:39905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pvxgs-0004X8-Df for 62762 <at> debbugs.gnu.org; Mon, 08 May 2023 06:01:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0E1792402B5 for <62762 <at> debbugs.gnu.org>; Mon, 8 May 2023 12:01:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1683540111; bh=oNUAZwev149qBGr9apIQfTvdrCHnpqYnB0b5VySTQao=; h=From:To:Cc:Subject:Date:From; b=hKiOmko/wiLQCXIO1UtZgX1+WlXiAJEu5OtkwzDc3IseGk4GLPjTrhxZlg+iYnDBF REhKsLtaP46q7gUG6gUaBfHuUMue5+PELDa5Q6+91HZEdPG7bzkMM34uR3VTvMxy+g kzT4KxPNOI6gygFosl5/le7dxe1xpyTgnt/E4gtlJwk76KXvrefYTgp7vtobMGHFm6 6raz4OOdR3bwm3820h5b68nA9vBsiWpRy/oOXqqOXaSKyjLGuttzKxVe5jOPnQTCHI Ug6ejNA5ChB1nCEUlhFxM+birb0ViGCBV2kOHTS4dOwlpeOK0i8hltCGVKpk3Tibgk ttgGjbQrnW+tg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QFGzL08d0z6tvn; Mon, 8 May 2023 12:01:49 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> <jwv5y95sju1.fsf-monnier+emacs@HIDDEN> <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> Date: Mon, 08 May 2023 10:05:05 +0000 Message-ID: <875y93kujy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Max Nikulin <manikulin@HIDDEN> writes: >> So, to me, (assuming the above is true) the remaining question is what >> Org developers want to do about `git pull; make` in Org's own repository. > > Perhaps `org-assert-directory' may be added to `org-assert-version' > > > (defun tst-assert-load-dir () > (let ((dir (tst-get-load-dir)) > (url "https://orgmode.org/worg/org-faq.html#mixed-install")) > (unless (equal tst-load-dir dir) > (error "Path shadowing detected, see <%s>. %s vs %s" > url dir tst-load-dir)))) Sounds reasonable. I think we can try to do the following: 1. Use the load-dir test, warn, and try to re-load 2. Use org-assert-version, but downgrade error to simple warning WDYT? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 7 May 2023 21:57:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 07 17:57:48 2023
Received: from localhost ([127.0.0.1]:38638 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvmO4-0005nX-0E
for submit <at> debbugs.gnu.org; Sun, 07 May 2023 17:57:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47958)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pvmO1-0005nK-Tf
for 62762 <at> debbugs.gnu.org; Sun, 07 May 2023 17:57:46 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9DC2B10011A;
Sun, 7 May 2023 17:57:40 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E4641000E7;
Sun, 7 May 2023 17:57:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683496659;
bh=Btudk+tiaGlf7/lcFqBlmVgNgJz9Y05EdtEhbvdRXJ8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=mQfdeiLkJ/rEvJ3KLyEuqxCjvsfJHuCbMll9dlB+8N8DRc4t/Wadaob9cPAYslTEy
x9FVmrWGjqceGnqUnG+oVBS/ux5ZRSWaH1Gw3bdsWS6vR5kwMHiyfu0bz+PKGLR39x
BCZDHtcFWCvd6lDWe45UHzjpjUeYjEIUeexSLrb5uOLhD8mSar0YpMnzVp97Sid/I9
dHHfW3Vpas3bqG8L0c9BBU+EV+4r9WCxHEKylpx0VHiob7hDxohYqOyLnbrY+I4xIb
Auoib+w7yAF6wLknDXveuOf9lHnpRODo5ZKyBAuTZkQtRS3wMdhwaot2LkEnL1TyYq
V+q+tTcWwIf9w==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E275B1201CB;
Sun, 7 May 2023 17:57:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN> (Max Nikulin's
message of "Sun, 7 May 2023 23:23:15 +0700")
Message-ID: <jwv3547q0gd.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
<03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN>
Date: Sun, 07 May 2023 17:57:37 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.194 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> AFAIU there are 2 main situations:
>> A) recompilation (i.e. `git pull; make`).
>> This can happen either in Org's repository or in Emacs's repository.
> ...
> Are there brave enough developers and users who do not restart emacs after
> rebuild of Emacs?
I recompile daily, and restart every other month or so?
FWIW, I never bumped into a problem with Org due to that (and never
used `org-reload` either).
>> B) mixed versions from different directories.
>> AFAICT `my-require-with-shadow-check` should be able to catch most/all
>> problems for (B),
>
> Agree.
>
>> without impacting (A), and more reliably than
>> `org-assert-version` (and in an arguably less ad-hoc way).
>
> Sorry, but `org-assert-version' should catch loading from the same directory
> a file compiled for new version since loaded earlier org-version.el defined
> old version that does not match `org-version' inscribed into new .elc
> files. I assume either combination of "make clean" and "make" or proper
> incremental build.
I'd consider these scenarios to fall into (A) or thereabout. And users
who do like I do (i.e. recompile Org while a session is using those Org
files) get what they deserve if they encounter a problem.
We have so many more real problems that I'm not interested in
considering such cases. I can give you a life-long supply of further
hypothetical cases if you're so inclined :-)
> By the way, if just org-macs should be checked then would not be it more
> efficient in respect to load time to define a variable containing the
> directory and to check in other files if they are loaded from the same
> directory? With such approach there is no need in walking through the
> `load-history' list.
You might be right. I was thinking in more general terms (e.g. I'm
thinking that maybe a test along the lines of the one performed by
`my-require-with-shadow-check` could be (optionally) included in
`require`).
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 7 May 2023 16:23:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 07 12:23:26 2023
Received: from localhost ([127.0.0.1]:38287 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvhAU-0004aV-1w
for submit <at> debbugs.gnu.org; Sun, 07 May 2023 12:23:26 -0400
Received: from mail-lf1-f52.google.com ([209.85.167.52]:62516)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1pvhAS-0004aI-1R
for 62762 <at> debbugs.gnu.org; Sun, 07 May 2023 12:23:24 -0400
Received: by mail-lf1-f52.google.com with SMTP id
2adb3069b0e04-4f139de8cefso23838084e87.0
for <62762 <at> debbugs.gnu.org>; Sun, 07 May 2023 09:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683476598; x=1686068598;
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=bzGqGzKSETiKWctOpVp6BnGHVkNm0damleA9vWbnCW0=;
b=ocarLOy8ft0mFvnPTuJ14xlDGqI06LuV0bONuwHM0xyMNY6FapKczqseb2sUp3Yew+
qwuOMnzoV2+V7T3G+uFed+x5RNLaErQyte7UNKYjkWHTswQbhTha5AfRgAJp5nZ1GGZU
cQ3FQuD8kiFpUjvx3QpA2hxvNl1/HQApH+imnkXsm1/ehvpM6+rfRG68vjuIIhmtNIF2
mcYUMWnZLgDj0RUJRUultMxrB+WyzBgscFMDLe8iFs06gB5+4Kov1TtU7z5Q/T0gwSoO
8emmXO64ncvE6ErJCYYebB9jZNBEeQUgE4lIU53uceLW/3Zd9mx58Z5w9XMu+fum/YgI
dRyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683476598; x=1686068598;
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=bzGqGzKSETiKWctOpVp6BnGHVkNm0damleA9vWbnCW0=;
b=UOPe+0QqkHz9KgI9z98kdtDFH+eNYdPPC9VYjVtCa7C8CckUs4xD9gEN8FE2WVd6nX
PtNgoS0QW+xOTp4Jt8mYZNQXR6FVWto/xtQel9f5bLYo5KgXXzyprsBrTlt8J2ZZ8Mre
E2lAsEk4LYVnW1mHcfcMTLvdrNtV1yY51wkquo8uPg3DRIV7gj0BtQXia7eJuDAs47hV
saV4E4Yh2ZmILyiV/0UpgWkgs+XPPKci1LwU2G9opI6ZIN4z3XOyp/mm3oRfi47iioxS
TnzWOI/l/xJxzyPD0oE0RsCCvTSIvTR1YpFrl8HQBBdzZ8pB9p375g/sbURzQKSX1h99
2hdA==
X-Gm-Message-State: AC+VfDxDgUjNICllYGmlyInPn+v6jQ2/IAwPVXX5ml6F/5lk4ffczM9T
IJpBQFDoSMQLjEtHpt47J+4=
X-Google-Smtp-Source: ACHHUZ7dVgWu/6tT6DZN/0RjQp21SvK+SNnaAJSHy5QlU7OKTDNHGdB6FCBVuTpLY+PPCGegzgiLeg==
X-Received: by 2002:a05:6512:230f:b0:4f1:21a2:9006 with SMTP id
o15-20020a056512230f00b004f121a29006mr3764546lfu.18.1683476597934;
Sun, 07 May 2023 09:23:17 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
l17-20020a05651c10d100b002ab0c9fab23sm856185ljn.79.2023.05.07.09.23.16
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 07 May 2023 09:23:17 -0700 (PDT)
Message-ID: <03d0e4f4-3855-fa3e-d502-bee77ea53b74@HIDDEN>
Date: Sun, 7 May 2023 23:23:15 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
<jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 06/05/2023 20:02, Stefan Monnier wrote: > AFAIU there are
2 main situations: > > A) recompilation (i.e. `git pull; make`). > This can
happen either in Org's repository or in Emacs's repository. ... [...]
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.167.52 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.52 listed in wl.mailspike.net]
-1.1 NICE_REPLY_A Looks like a legit reply (A)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 06/05/2023 20:02, Stefan Monnier wrote: > AFAIU there are
2 main situations: > > A) recompilation (i.e. `git pull; make`). > This can
happen either in Org's repository or in Emacs's repository. ... [...]
Content analysis details: (1.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.52 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.167.52 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.1 NICE_REPLY_A Looks like a legit reply (A)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
On 06/05/2023 20:02, Stefan Monnier wrote:
> AFAIU there are 2 main situations:
>
> A) recompilation (i.e. `git pull; make`).
> This can happen either in Org's repository or in Emacs's repository.
...
Are there brave enough developers and users who do not restart emacs
after rebuild of emacs? Some Org users hope that `org-reload' works and
they can update Org without restarting Emacs.
> B) mixed versions from different directories.
>
> AFAICT `my-require-with-shadow-check` should be able to catch most/all
> problems for (B),
Agree.
> without impacting (A), and more reliably than
> `org-assert-version` (and in an arguably less ad-hoc way).
Sorry, but `org-assert-version' should catch loading from the same
directory a file compiled for new version since loaded earlier
org-version.el defined old version that does not match `org-version'
inscribed into new .elc files. I assume either combination of "make
clean" and "make" or proper incremental build. That is why I disagree
with "without impacting (A)".
> So, to me, (assuming the above is true) the remaining question is what
> Org developers want to do about `git pull; make` in Org's own repository.
Perhaps `org-assert-directory' may be added to `org-assert-version'
By the way, if just org-macs should be checked then would not be it more
efficient in respect to load time to define a variable containing the
directory and to check in other files if they are loaded from the same
directory? With such approach there is no need in walking through the
`load-history' list.
==> tst-macs.el <==
(defun tst-get-load-dir ()
(file-name-directory
(or load-file-name
;; For `eval-buffer'.
(buffer-file-name (buffer-base-buffer)))))
(defvar tst-load-dir (tst-get-load-dir))
(defun tst-assert-load-dir ()
(let ((dir (tst-get-load-dir))
(url "https://orgmode.org/worg/org-faq.html#mixed-install"))
(unless (equal tst-load-dir dir)
(error "Path shadowing detected, see <%s>. %s vs %s"
url dir tst-load-dir))))
(provide 'tst-macs)
==> tst-main.el <==
(require 'tst-macs)
(eval-and-compile
(if (fboundp 'tst-assert-load-dir)
(tst-assert-load-dir)
(error "Path shadowing detected, see
<https://orgmode.org/worg/org-faq.html#mixed-install>")))
(provide 'tst-main)
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 7 May 2023 05:33:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 07 01:33:52 2023 Received: from localhost ([127.0.0.1]:36191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pvX1s-0005yq-B2 for submit <at> debbugs.gnu.org; Sun, 07 May 2023 01:33:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pvX1q-0005yb-2a for 62762 <at> debbugs.gnu.org; Sun, 07 May 2023 01:33:51 -0400 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 <eliz@HIDDEN>) id 1pvX1i-00078P-OV; Sun, 07 May 2023 01:33:42 -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=vzewGUFcMnQ3WahvzNEqUs3fWL88MqDn4lqcT9AJIEw=; b=RQ+PplYe0feV rBYOvUguLN68Cy6pmYVi2ApR9fa5gQr6BGOJDs4ehD7BB9yuM0oXusxmAEKPIvkcq0HZuCfCAUkIS FuRJ7ufQe2TepSywYAer+0FqnjfQ6POtU8g3FsDje5FQOadbyjS1HjylVfZrnwW+h7FWdo9kFppFD vZ5+DbQgC2kixOGMpp6mRukpf6N55Q2u2BoGuWZIcPydEAC7gFsEsUmQzwbdMlKBQiCGy4VWPHZtK d9jHONOWpPi57CRFpR/YsMgavJz1JBLpd5LuSB16Op3o0rB1KjdKeWnvZJ502SYv4ovcsM6/8Txvj y+KUXZf3LUxAJzVQD64McA==; 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 <eliz@HIDDEN>) id 1pvX1i-0007tR-4d; Sun, 07 May 2023 01:33:42 -0400 Date: Sun, 07 May 2023 08:34:38 +0300 Message-Id: <83y1m0emc1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <3d9869dc-8cac-e076-ba7e-def76bfc587c@HIDDEN> (message from Max Nikulin on Sun, 7 May 2023 09:45:20 +0700) Subject: Re: Incremental builds and Lisp files dependencies pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> <83h6sphp82.fsf@HIDDEN> <0d716705-bea1-4cb3-afbc-c381a7519b12@HIDDEN> <83fs89fmtj.fsf@HIDDEN> <3d9869dc-8cac-e076-ba7e-def76bfc587c@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 7 May 2023 09:45:20 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 06/05/2023 23:26, Eli Zaretskii wrote: > >> Date: Sat, 6 May 2023 22:50:22 +0700 From: Max Nikulin > >> > > No, I mean that the order in which Make builds the targets might not > > be what you think, if all you tell it that all org/*.elc files depend > > on org-macs.elc. > > Sorry, but it is still not clear to we what "doesn't really work" and I > feel that it may be important for further discussion. > > If a Makefile contains a dependency like > > org/ol.elc: org/org-macs.elc > > and org/org-macs.elc needs update then the rule for org/ol.elc is > executed after completion of the rule for org/org-macs.elc. The purpose > of dependencies is to define order of execution of build rules. My point was that with the above rule, if org-macs.elc doesn't exist, Make will want to produce it, even though for your purposes there's no reason to do that. > However I suggested dependencies on org-macs.el, not on org-macs.elc: > > Sat, 6 May 2023 13:00:38 +0700 > >> they > >> should be at least that all lisp/org/*.elc files depend on > >> lisp/org/org-version.el and lisp/org/org-macs.el. I don't really understand in enough detail what is it that you are suggesting, because you show your suggestion piecemeal. Can you describe the suggestion in its entirety, top to bottom, including all the details? In particular, since the proposed automatic dependency generation will be side effect of byte-compilation (right?), how do you make sure the compilation is in the correct order when dependencies change due to changes in the source *.el files? Please also consider parallel builds, something that almost all of the Emacs developers use all the time. Thus, if N files depend on foo.el, when foo.el changes Make will want to run N parallel jobs compiling each one of the N dependencies. In addition, some of the *.el files are generated, so they change as result of changes in other *.el files. AFAIK, automatic dependency generation doesn't usually deal with such cases, it only deals with dependencies on files that are not regenerated as part of the build. How do you suggest to handle this? And finally, some of the Lisp files are preloaded, so their changes, and the changes in their *.elc files as result of changes in their prerequisites, affect the Emacs binary that is used to byte-compile the Lisp files. If the preloaded files are outdated, many compilations might fail just because of this aspect. If you have an idea for solving all of these problems (which are really just the initial tips of the iceberg), please describe your idea with all of its details. Otherwise, this discussion is not really useful.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 7 May 2023 02:45:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 22:45:35 2023
Received: from localhost ([127.0.0.1]:36087 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvUP0-0000sh-MY
for submit <at> debbugs.gnu.org; Sat, 06 May 2023 22:45:34 -0400
Received: from mail-lf1-f41.google.com ([209.85.167.41]:62742)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1pvUOv-0000sR-W8
for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 22:45:34 -0400
Received: by mail-lf1-f41.google.com with SMTP id
2adb3069b0e04-4f00d41df22so23066531e87.1
for <62762 <at> debbugs.gnu.org>; Sat, 06 May 2023 19:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683427524; x=1686019524;
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=fX/yRLykLtlk9TVApHCQdNYWr6MbO0O5U9/DASrq0bw=;
b=nMAyo30vLEyWo2nRT84O5mC9HiQqklGuvCoX+xbuB0OcQZJVLE5aetJEv8OqhN0PXM
O4VDzzzdY3QvF9SaXNRElE3OwS6D32A/kgBiVmVLmD86eO/d4ofsTmXHrpMrv5ITNs7j
3j52Smmeani5dWvVlE9spxEttKjdd6oU9ZEzlyBZKERbcrH26Q+mVQSZjBz6MDSgWHdd
AyJHgHQfD6eMuULW4L+H6WEFUbi4JCvaNpg7cVstkNSBrZPRmdEbh/8wuEufiwGgc7o8
Xuc0W98Kqg7Uar6r9nsYn23gIFjp0VitKAU2wJHddtg1rX2Cbpe6LV3ttIE5xG4EZ0sZ
52WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683427524; x=1686019524;
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=fX/yRLykLtlk9TVApHCQdNYWr6MbO0O5U9/DASrq0bw=;
b=cP+9VIINKYdrDLr5OfYU1KkZL44rZnPB513luQ63QNkXrHZVT1fqFNNBQT65LdF9h2
QXMI0BAA0fa2ju9dFpawbXHZH5S3MpOHHlF1oY93nML1DkpMN7KbUjElDs56d6xGbZxa
G0SMEpOcmQdfamfeMC8FrTMdpyphVLW2Y648hIDSK1cDefbwF3ICqvdAlwCKnybL2bba
CSeK1JzBDmsx2bYKKVyQPKKhasKzw9pvfcrcJELcB4KWCEpvZCbBJdVwyR5BZTMUwVHE
ID3/qPFdQEO2c4uSb76+4p9tamPTVzGaHiQahYfO+ifBlnnjOwKqRk9wkpfbz/n8c22N
yIlw==
X-Gm-Message-State: AC+VfDxHLGd+OsnqB8WW+iTnPHaIsEfZ8dLfneByFFuOQcoxdvTdWyah
qbPv/dDWQeu6JHSjNdEFNLc=
X-Google-Smtp-Source: ACHHUZ6ry8VySeZDVpm2NJGaBc361/kP4iSpbJQTf1pyJ0HrNauKrNsgcKCbj2WDiu4kYxknAxPcgw==
X-Received: by 2002:a05:6512:10c4:b0:4f1:4a14:d97c with SMTP id
k4-20020a05651210c400b004f14a14d97cmr1550507lfg.16.1683427523665;
Sat, 06 May 2023 19:45:23 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
e3-20020ac25463000000b004efff420b11sm829027lfn.181.2023.05.06.19.45.22
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 06 May 2023 19:45:23 -0700 (PDT)
Message-ID: <3d9869dc-8cac-e076-ba7e-def76bfc587c@HIDDEN>
Date: Sun, 7 May 2023 09:45:20 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Subject: Re: Incremental builds and Lisp files dependencies pulling a new
version of the code
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> <83h6sphp82.fsf@HIDDEN>
<0d716705-bea1-4cb3-afbc-c381a7519b12@HIDDEN> <83fs89fmtj.fsf@HIDDEN>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <83fs89fmtj.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 06/05/2023 23:26, Eli Zaretskii wrote: >> Date: Sat, 6
May 2023 22:50:22 +0700 From: Max Nikulin >> >> On 06/05/2023 14:51,
Eli Zaretskii
wrote: >>> This doesn't really work, not as long as we use [...]
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.167.41 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.41 listed in wl.mailspike.net]
-1.1 NICE_REPLY_A Looks like a legit reply (A)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
monnier@HIDDEN, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 06/05/2023 23:26, Eli Zaretskii wrote: >> Date: Sat, 6
May 2023 22:50:22 +0700 From: Max Nikulin >> >> On 06/05/2023 14:51, Eli Zaretskii
wrote: >>> This doesn't really work, not as long as we use [...]
Content analysis details: (1.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.167.41 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[5.44.169.188 listed in zen.spamhaus.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.167.41 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (manikulin[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.1 NICE_REPLY_A Looks like a legit reply (A)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
On 06/05/2023 23:26, Eli Zaretskii wrote:
>> Date: Sat, 6 May 2023 22:50:22 +0700 From: Max Nikulin
>>
>> On 06/05/2023 14:51, Eli Zaretskii wrote:
>>> This doesn't really work, not as long as we use Make: some *.elc files
>>> might not exist yet, for whatever reasons, so Make will try to
>>> generate them first, thus disrupting the order of generation that you
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> will try to encode in the dependencies. We already tried that, and it
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> didn't work, not even just for Org.
>>
>> Could you, please, be more precise? Do you suspect that Make may start
>> building a target before completion of all rules for its prerequisites?
>
> No, I mean that the order in which Make builds the targets might not
> be what you think, if all you tell it that all org/*.elc files depend
> on org-macs.elc.
Sorry, but it is still not clear to we what "doesn't really work" and I
feel that it may be important for further discussion.
If a Makefile contains a dependency like
org/ol.elc: org/org-macs.elc
and org/org-macs.elc needs update then the rule for org/ol.elc is
executed after completion of the rule for org/org-macs.elc. The purpose
of dependencies is to define order of execution of build rules.
However I suggested dependencies on org-macs.el, not on org-macs.elc:
Sat, 6 May 2023 13:00:38 +0700
>> they
>> should be at least that all lisp/org/*.elc files depend on
>> lisp/org/org-version.el and lisp/org/org-macs.el.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 6 May 2023 16:25:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 12:25:55 2023 Received: from localhost ([127.0.0.1]:35650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pvKjL-00066R-0W for submit <at> debbugs.gnu.org; Sat, 06 May 2023 12:25:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pvKjF-00066B-Kr for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 12:25:53 -0400 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 <eliz@HIDDEN>) id 1pvKj8-0001y2-NA; Sat, 06 May 2023 12:25:42 -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=f+bxBiFV8OyCh96l4NWKadDnBSk8GTUMwnw0Iq46+Ek=; b=REYcYiujYcW3 Fr8SOEuklPv6GKuSNUAXclzAiS2QGDjzSRjzmSn9HREQHh4eF8bKPxE3gokm/WjffHy7cFJanUd6i VQSiu1UsN/Ibb06PToFmcAGztPBNy4pbtrYAr85MkOAnBkvmrLBgS/Vy/oe1BjXuJMz7Pfm+LEtEI tyCjQaEd3/CYrqWTdLk99XZiLSBG/5Cob6zKaH7WjtKX3ogbQ4jFCfAmaVoYIXCJQ+RIK/K/tIMhC t4rv2sw1ADOWLXbjUpGjSYQIsXpc5Aiwcm/aHlWHcAgvyhsUH0cl2J5AjspkliimfFLqH0gDC0Bcs JMT6elf8lQVk6favD81pXA==; 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 <eliz@HIDDEN>) id 1pvKj3-00008C-38; Sat, 06 May 2023 12:25:41 -0400 Date: Sat, 06 May 2023 19:26:32 +0300 Message-Id: <83fs89fmtj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <0d716705-bea1-4cb3-afbc-c381a7519b12@HIDDEN> (message from Max Nikulin on Sat, 6 May 2023 22:50:22 +0700) Subject: Re: Incremental builds and Lisp files dependencies pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> <83h6sphp82.fsf@HIDDEN> <0d716705-bea1-4cb3-afbc-c381a7519b12@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 6 May 2023 22:50:22 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 06/05/2023 14:51, Eli Zaretskii wrote: > > This doesn't really work, not as long as we use Make: some *.elc files > > might not exist yet, for whatever reasons, so Make will try to > > generate them first, thus disrupting the order of generation that you > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > will try to encode in the dependencies. We already tried that, and it > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > didn't work, not even just for Org. > > Could you, please, be more precise? Do you suspect that Make may start > building a target before completion of all rules for its prerequisites? No, I mean that the order in which Make builds the targets might not be what you think, if all you tell it that all org/*.elc files depend on org-macs.elc.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 6 May 2023 15:50:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 11:50:35 2023
Received: from localhost ([127.0.0.1]:35580 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvKB8-00051N-UP
for submit <at> debbugs.gnu.org; Sat, 06 May 2023 11:50:35 -0400
Received: from mail-lf1-f53.google.com ([209.85.167.53]:53398)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1pvKB5-00050t-6X
for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 11:50:34 -0400
Received: by mail-lf1-f53.google.com with SMTP id
2adb3069b0e04-4f11d267d8bso3261426e87.2
for <62762 <at> debbugs.gnu.org>; Sat, 06 May 2023 08:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683388225; x=1685980225;
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=qdPOSTq81Uxx8m9fP1i78ZORRX1WQC9e2UHQRpI0TMo=;
b=bzgZHGf3CKkBfsQ+nvfZGdiBYTeqZncUIcMio5AvqTU2+ysZQXNxweViZ+I9kcJYEm
g7vpPTY/kw6Zc+R3FvPAqS9gCnMADLDePgY53XIZsv/Xwcy2RkwPyoK7vfKmJRLR2L0U
er/xKOK7KWOh9s8SEK7qp8fXjes4vnKoMGDNx1ak2+yxL4H77nUjRXjXWvMToPnMXl6T
U8qlIgjatc9mdcxOqCgdWtgC6EnYjK0Y+D0rs5cRK6IoDlocaimVLVFw49arv6j5Rxfp
4MMtG9hW/sercccJbtWzR8i7N/DpPWEXlz+YEUPdqps4O/nlB9XZLHI031Diy33zkCxJ
O22w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683388225; x=1685980225;
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=qdPOSTq81Uxx8m9fP1i78ZORRX1WQC9e2UHQRpI0TMo=;
b=V070RtLkoKn/kOC6EJgzBrUjjVieQcERdGcM3Dyk3Am6toayaoiZO/pVPHNYBByuoQ
lLOH5qRSTmRKpe+OgHopZKQVq7SfhJNmOKUyHPEEtHLD+GMup7SBLzekeDmnTSTCrh7i
3qmRufOipbCS0Lv8cpDPrQtvxo5JGNp7oGI/Fhs+UraL6qwISeinog+KEQUOTMl3wRVz
zGc0FNu/7YOM8LtL9CiiSFokqNUboOcFNOLmQTmoiNP4J7cu8Fpq6sTCNv1VsqljFqQf
4hwa9PtFtVN2f4/jAARDxNSwrtwC/BEk6V/l+qazwbNFbGlgEMTwKvUb1agrbC7i+hVG
qgrA==
X-Gm-Message-State: AC+VfDyV2WfNlyWCZXHNgLTrIl4YbgjlThNrMKm3ynZhI2GpnVYn3IKR
2uxSIaFKItAFKZ4adfnPiqA=
X-Google-Smtp-Source: ACHHUZ7YAM2x9tvdl84ripZYDSvpycWBWdjlq9G62/RbO0zeDLD2D9UHfhduyKuDv/z3OQp3HTjZZA==
X-Received: by 2002:a19:ee10:0:b0:4f0:e03:75d9 with SMTP id
g16-20020a19ee10000000b004f00e0375d9mr1306212lfb.48.1683388224867;
Sat, 06 May 2023 08:50:24 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
q4-20020ac25284000000b004ec55ac6cd1sm693688lfm.136.2023.05.06.08.50.23
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sat, 06 May 2023 08:50:24 -0700 (PDT)
Message-ID: <0d716705-bea1-4cb3-afbc-c381a7519b12@HIDDEN>
Date: Sat, 6 May 2023 22:50:22 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Subject: Re: Incremental builds and Lisp files dependencies pulling a new
version of the code
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> <83h6sphp82.fsf@HIDDEN>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <83h6sphp82.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
monnier@HIDDEN, acm@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
On 06/05/2023 14:51, Eli Zaretskii wrote:
> This doesn't really work, not as long as we use Make: some *.elc files
> might not exist yet, for whatever reasons, so Make will try to
> generate them first, thus disrupting the order of generation that you
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> will try to encode in the dependencies. We already tried that, and it
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> didn't work, not even just for Org.
Could you, please, be more precise? Do you suspect that Make may start
building a target before completion of all rules for its prerequisites?
It sounds like a grave bug in Make.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 6 May 2023 13:02:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 09:02:45 2023
Received: from localhost ([127.0.0.1]:59648 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvHYi-0007iB-TF
for submit <at> debbugs.gnu.org; Sat, 06 May 2023 09:02:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59225)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pvHYg-0007hy-TC
for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 09:02:44 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 50B018080C;
Sat, 6 May 2023 09:02:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F0745802BB;
Sat, 6 May 2023 09:02:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683378156;
bh=YWbelTQE1ZRRApWDUZ+DxTWHqj/9EanI+IF/VMbmn0M=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=RhKPuXcukNTNY1IE/TLLpmn9mJj+5JeovsKDIiJup/3aAwrVixsWlKrOitZ/XkAYR
UVdaSd2eEazEkja2VpjFH1/dbupVLTNc5hwJQ5eF2qPaKV5FK8wClVphdXuK0z7oof
J9ue98LkRk3bgTTEBBjos7+MYFUT9bsxR4uMULLvMXH8jWbD49Z52mH2wq+XjHUmbp
agOxmODRQ0FGLVFERNyqhnKwUX9tIcx8oLS5hR1i4PTkdXnaoejPoHqFUzfLouDkBE
lYS+OxpMDyhGwhZRus1q4muSjH5NOq0+qPgGwtor5ljWsOwkC0PodaIHXOB4equhag
Q2ecgOJ/xm8vA==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A3BCE1202A2;
Sat, 6 May 2023 09:02:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN> (Max Nikulin's
message of "Sat, 6 May 2023 12:25:42 +0700")
Message-ID: <jwv5y95sju1.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
<jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
<5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
Date: Sat, 06 May 2023 09:02:34 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.118 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
AFAIU there are 2 main situations:
A) recompilation (i.e. `git pull; make`).
This can happen either in Org's repository or in Emacs's repository.
For Emacs repository, Emacs maintainers prefer recompilation to be
faster even if it implies occasional breakage (clearly, the details
matter to know which of the two evil we prefer, but we're not
interested in "fixing of real cause" unless it's cheap enough).
B) mixed versions from different directories.
AFAICT `my-require-with-shadow-check` should be able to catch most/all
problems for (B), without impacting (A), and more reliably than
`org-assert-version` (and in an arguably less ad-hoc way).
So, to me, (assuming the above is true) the remaining question is what
Org developers want to do about `git pull; make` in Org's own repository.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 6 May 2023 07:50:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 03:50:59 2023 Received: from localhost ([127.0.0.1]:58685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pvCh0-0004Ud-Qj for submit <at> debbugs.gnu.org; Sat, 06 May 2023 03:50:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pvCgy-0004Th-6s for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 03:50:56 -0400 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 <eliz@HIDDEN>) id 1pvCgq-0002Ow-MP; Sat, 06 May 2023 03:50:48 -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=dP+1+GsLXQu9Q7Z0mTFQb/tYKTb36eAYm/dHlkFk9R4=; b=h3ZrOfivfjdQ DsWcO+DLFYOSXLuut4huPmH8NIaxURuXJLM2wnDgSoFAeCoHHliTcYHfiOl7EuMC3Q4dQigzNCPwu pvewcDLnfwUFsA6A94saXAYV7ItWNmRU8nwmhjteoIFv0B3UA4PsbwFXJOzBMooJQX9viM7/XlNMG BAY6+Mb/xEx8TCdZ3Tjf0Ft6MkkjO7LAeMUVNuuOfviW4rWFQQsV78PM85LQa4EeVwKDxWNl4YqcN wdsqBb5vI5aju6waAKYvh09E80w/fA/Qd+PnJD+JDXifVX6odIFztJmOci/TU8HsyJOHRFfrkC0/o FqJ8yZTET9z9k81dYCrfNA==; 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 <eliz@HIDDEN>) id 1pvCgq-0006M1-3B; Sat, 06 May 2023 03:50:48 -0400 Date: Sat, 06 May 2023 10:51:41 +0300 Message-Id: <83h6sphp82.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> (message from Max Nikulin on Sat, 6 May 2023 13:00:38 +0700) Subject: Re: Incremental builds and Lisp files dependencies pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> <1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 6 May 2023 13:00:38 +0700 > Cc: Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, > Alan Mackenzie <acm@HIDDEN> > From: Max Nikulin <manikulin@HIDDEN> > > On 06/05/2023 01:17, Stefan Monnier wrote: > > I'll refrain from discussing this here. Incremental recompilation > > problems should be discussed in another bug report, IMO. > > I will try to explain why this bug report was caused by issues with > incremental builds. I've started a new thread, because I agree with Stefan: this is a separate issue. Please reply with this new thread's Subject. > Let's assume that a trouble with cyclic dependencies is a real one (I > have not convinced in that). A way to the correct builds is to > *completely* avoid loading of .elc files during incremental builds. When > only a few files changed then relying purely on .el files should cause > significant performance penalty. Exactly. And please don't forget that quite a few files are preloaded, so using only *.el means to preload only the *.el files, which will result in a significantly slower bootstrap-emacs binary, and the build will become annoyingly slow, for no good reason. > Unfortunately it would not work without > describing at least some dependencies. In the `org-assert-version' they > should be at least that all lisp/org/*.elc files depend on > lisp/org/org-version.el and lisp/org/org-macs.el. Without automatic > dependency generation it is a kludge, but it should significantly > alleviate the issue. This doesn't really work, not as long as we use Make: some *.elc files might not exist yet, for whatever reasons, so Make will try to generate them first, thus disrupting the order of generation that you will try to encode in the dependencies. We already tried that, and it didn't work, not even just for Org. > Commits pushed so far trade false positives to false negatives and to > reports of bugs due to "undefined" functions and incorrect signatures to > Org developers and maintainers. Those commits only affect byte compilation of Org as part of building Emacs, so I see no reason why they should cause the above issues for Orge developers. > Perhaps `org-assert-version' may be improved, but this report was caused > by broken build rules. The bug#62762 was reported because Org behaved unlike any other Lisp package in Emacs. We have other packages that define macros used in many other *.el files, and none of them does the version-check like Org did. The problems with making incompatible changes in one or more of the macros are well known to Emacs developers who rebuild Emacs frequently, and we have ways to deal with them. Some of those ways (the simplest ones) are encoded in the top-level Makefile, see ADVICE-ON-FAILURE there. There are others, more subtle ones, for those, like myself, who don't bootstrap, ever, except the first time a fresh repository is cloned. That Org behaved in a stark different manner was therefore an unpleasant annoyance, so we now fixed that by making Org behave in this regard like any other Lisp package in Emacs -- but only when Emacs is built, because the knob which forces this behavior is off by default, and is only turned on by lisp/Makefile in the Emacs tree.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 6 May 2023 06:00:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 02:00:52 2023 Received: from localhost ([127.0.0.1]:58036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pvAyS-0001SK-8l for submit <at> debbugs.gnu.org; Sat, 06 May 2023 02:00:52 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:45135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pvAyM-0001S5-Rm for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 02:00:50 -0400 Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-4ecb137af7eso2942576e87.2 for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 23:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683352841; x=1685944841; 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=oZjUN6Xap080AxjOrL2TX1AlPv1/CzSrCUSNxQUKrjU=; b=FDLymWnFblGW4enKB5ByCRfd4H2wB+UXEG3eWh3vIhq2UoFUsUh4m2NxY1uoiqjLHA Vi7WI55vLyA453AjNexst1XhRz7fZlWglueP6RKe9TQ6iDgo/dw3CSl0zfsEHT7JP0Br 95JmW6v2BhQi7iLtZzyb+ZLf4KfPuwA363CTPkm979JRK+1nPDCB6fTSATsImtxhAZrs vGFbckqWb/2DcADqUy99u9P2lT8rnfMw3JDenRTQ11wPIQ6+eQ+rtC0oLSkGhJPPYN9/ AqV2Ca4xUX16i8zKSO8FYU7IIUJhCuh7LzotRaOjvGe42upIwD6BPe0VNqQ0YClqb5OH 3pJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683352841; x=1685944841; 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=oZjUN6Xap080AxjOrL2TX1AlPv1/CzSrCUSNxQUKrjU=; b=XfY6NAjtS2UkeSkwg1gc3bB12drQFNMhKoOGMpLyvktG+7cmb03fioAsYbGErfaX42 FjJxwHA91b2bYwDdcpWKfVYcQluPosTJjqfRRbXeC3qTawa8RGlojWpw7OuwbBSVaTSG p3xYjSe3jgzsK7u/vidLFaKk6lRgAGQWywObxNuRyEOPyYVK262NQ7/HcaW+uparEbJ9 bBSjFIuAWma2Kkt8oVq508Tdk2RbltXgZs6sbPTTKVQGKeKvJle96/twE5ci2DsyfQWf MG7W6AhbX4SV+XYSydOEkX8XT8ZVqEC/wcXa0UZ3nxioTpAPmk8vnTBUfRcY0xYUdYlI 077Q== X-Gm-Message-State: AC+VfDxZ1mFsdutR7ZNypEBz/OjxKolsdzQe/lJWpU2B+vZ2UZnTO5b0 u9YwOEz1UZktHTqML/eJI+w= X-Google-Smtp-Source: ACHHUZ4LiFAEMp2IzHEf+afsqj4hbfRR6GP/qhEx5f3YH5Pww5+1ISRNgmVzZZrEeS11e6Roy/P/fw== X-Received: by 2002:ac2:5d6b:0:b0:4eb:dd2:f3d2 with SMTP id h11-20020ac25d6b000000b004eb0dd2f3d2mr1152164lft.43.1683352840804; Fri, 05 May 2023 23:00:40 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id v12-20020ac2592c000000b004edc3f06f5csm532639lfi.296.2023.05.05.23.00.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 23:00:40 -0700 (PDT) Message-ID: <1f236996-5f17-3be8-d01c-803e065985f7@HIDDEN> Date: Sat, 6 May 2023 13:00:38 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <jwvo7myejmd.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 06/05/2023 01:17, Stefan Monnier wrote: > I'll refrain from discussing this here. Incremental recompilation > problems should be discussed in another bug report, IMO. I will try to explain why this bug report was caused by issues with incremental builds. Original report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#5 > Could someone fix that, so that I don't have to 'make bootstrap' every > other time after a 'git pull'? > > make[3]: Entering directory '/home/dgutov/vc/emacs-master/lisp' > ELC org/ox.elc > Warning (emacs): Org version mismatch. Org loading aborted. It may be a *valid* error, however on minor Org updates it is likely a false positive. ox.el has a number of `require's. Byte compilation loaded an .elc file before it was recompiled with new definition of a macro. Notice that an .elc file may become stale even if the corresponding .el file has not changed. The .el file may require macros from other .el (.elc) files and expand them during compiling. So incremental build must compile files in certain order. It must take into account dependencies between .elc and .el files and prevent loading of stale .elc files. `load-prefer-newer' can be a workaround only for direct "%.elc: %.el" dependencies. Transitional dependencies still may cause troubles. Let's assume that a trouble with cyclic dependencies is a real one (I have not convinced in that). A way to the correct builds is to *completely* avoid loading of .elc files during incremental builds. When only a few files changed then relying purely on .el files should cause significant performance penalty. Unfortunately it would not work without describing at least some dependencies. In the `org-assert-version' they should be at least that all lisp/org/*.elc files depend on lisp/org/org-version.el and lisp/org/org-macs.el. Without automatic dependency generation it is a kludge, but it should significantly alleviate the issue. Grepping org sources for defmacro and adding e.g. org-element.el dependency will make incremental builds with stale macro definitions even more rare. Commits pushed so far trade false positives to false negatives and to reports of bugs due to "undefined" functions and incorrect signatures to Org developers and maintainers. Perhaps `org-assert-version' may be improved, but this report was caused by broken build rules.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 6 May 2023 05:25:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 06 01:25:56 2023
Received: from localhost ([127.0.0.1]:58015 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pvAQd-0000FW-OY
for submit <at> debbugs.gnu.org; Sat, 06 May 2023 01:25:56 -0400
Received: from mail-lj1-f179.google.com ([209.85.208.179]:56625)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1pvAQY-0000FC-Bk
for 62762 <at> debbugs.gnu.org; Sat, 06 May 2023 01:25:53 -0400
Received: by mail-lj1-f179.google.com with SMTP id
38308e7fff4ca-2ac7de2b72fso29607581fa.1
for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 22:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683350744; x=1685942744;
h=content-transfer-encoding:in-reply-to:cc:content-language
:references:to:subject:from:user-agent:mime-version:date:message-id
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=MsMlcltME9TO9vOLOwn1GfsqdnGJboneD85mND0ps3s=;
b=RKg/U7Tv5fk2JKWBZA6wZUIig9DSqpUnbCn8txvoVfg7jGQ/pNcHiIuRsmCuZO7ND2
NamtJDVcPERApZGX973Wma6cdp5Ds+UrGgFjpIgnh41Q64ceo2k5RdPDOtXLinh7rMrD
eFvqwEjzOopaUQoTp3XeupKpUvJBXFLGrqxY5Xu1zSFR3qAeH6PVBqxeRHwFZom+zPxp
49QRr8YTXmWJa1ODvx1zwm30cS2azG0sFmKox6NjgecixNJTYGcUu56WEQMS+WfA8Pke
2eCtGQ1Gtr88AAFeDikRfVgsoCZ8MtvWZ/S8krDSilweOgXWmNukHosJwNdfGnX64NAd
+fqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683350744; x=1685942744;
h=content-transfer-encoding:in-reply-to:cc:content-language
:references:to:subject:from:user-agent:mime-version:date:message-id
:sender:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=MsMlcltME9TO9vOLOwn1GfsqdnGJboneD85mND0ps3s=;
b=Q8xLfuYzagM5PxfY4GSiWLWDhSaVuqzv6wq9N/oucWPrUfSpePytNbfEN2DNOk0Q3k
BNIVV5RbiPFQSmCMwHbjuxWpcjoPp0dOfJIqJW/fZnwVVS9xmNnqDE559JlPQi7/nGkZ
74KDtQebBOORwATh1HY3jnsDgrL7DeFdWeyFMYndWtBDEB+HSzIweq7E/leLD1DlY5Cg
p/nOq9fAvjbqNMvJaPM00DSYkE3mfP/A31cmbynhJdIzD9bJRJd4JArmk1UJoDhfyslC
uLbeiDUIcnwWMom4SgisJoemN6qyC3/MLADni1YDzdw+eRerCC3uZ11o2NBtAWHtI5V6
B3Zg==
X-Gm-Message-State: AC+VfDw+BKjVzQfuI97+FbbkOJaJNcEnCckF+1kmO6xs/vOly5ZSDLQt
McYL98FUfnP1CmRKORbzCiI=
X-Google-Smtp-Source: ACHHUZ4zvlGOHHU2/wJcoKOen+Wf2h2vmiAOQKUzLLBh9013jhQ81EkjHEMvQrvTOS0GYSkWaBMO7w==
X-Received: by 2002:a2e:968b:0:b0:2a8:b300:acb5 with SMTP id
q11-20020a2e968b000000b002a8b300acb5mr911704lji.9.1683350744008;
Fri, 05 May 2023 22:25:44 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
c24-20020a05651c015800b002a9ebff8431sm250062ljd.94.2023.05.05.22.25.42
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 05 May 2023 22:25:43 -0700 (PDT)
Message-ID: <5603ba14-8120-cf38-05ba-4435c1bece3f@HIDDEN>
Date: Sat, 6 May 2023 12:25:42 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
From: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
To: Stefan Monnier <monnier@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
<jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
Content-Language: en-US
In-Reply-To: <jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Stefan, my apologizes that I sent first copy exclusively to you.
On 06/05/2023 01:17, Stefan Monnier wrote:
>> I have no ideas how to make `org-assert-version' better.
>
> `my-require-with-shadow-check' is a suggestion to make it better.
My current opinion is that `my-require-with-shadow-check' may be an
improvement when *combined* with original `org-assert-version' (that
inscribes org-version into .elc files).
The reason why `my-require-with-shadow-check' may be significantly less
efficient if it will *replace* original implementation of
`org-assert-version' is the following.
Consider a user who cloned org-mode git repository and loads Org mode
from there with periodic pull and rebuild actions. Forget about built-in
Org and assume that `load-path' is modified early enough to not cause
any problem.
Now literally citing my Fri, 5 May 2023 11:18:17 +0700 message
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#140
Does in help in the following case?
1. Base Org part is loaded on opening of some .org file.
2. Org in that directory is updated and recompiled.
3. New Org feature is loaded (autoloaded or by explicit call of e.g.
(require ob-shell))
Additional argument:
When the reporter got the error from `org-assert-version' it was not
necessary a false positive (however most probable on minor version
update), user may face an error later while running Org because not all
files were recompiled after changes in macros.
I am in doubts if `my-require-with-shadow-check' may help in such cases.
> And this sub-thread of the bug report was presumably your answer to the
> question by Ihor:
>
> Max, do you see any obvious downsides in Stefan's idea about consulting
> `load-history' vs. `load-path'?
My excuses:
- message subject has not changed, so it was unclear that it was decided
to discuss purely mitigation of symptoms instead of fixing of real cause
- participants of discussion are spread across time zones, so a longer
messages may be preferred
- Configuration of https://debbugs.gnu.org is worse than
https://bugs.debian.org, reply to specific messages links are missed.
- debbugs and thunderbird are not friends in respect to mbox links (and
I have not created a wrapper script that should work as a workaround)
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 5 May 2023 18:27:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 14:27:11 2023
Received: from localhost ([127.0.0.1]:57459 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pv098-00031x-V4
for submit <at> debbugs.gnu.org; Fri, 05 May 2023 14:27:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9799)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pv096-00031g-DE
for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 14:27:09 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9319310019A;
Fri, 5 May 2023 14:27:02 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C34081000C4;
Fri, 5 May 2023 14:27:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683311220;
bh=Sjc6yNO7oMzhT1FpB4TvApGp9+07enux57jJ1Co5lTo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=IB4GG3M0/dminpdRbcX6WfbpyuHmKiF7aHyYXOP0bcVjm4MzRZGIOM3mQR9pHtPzR
cfl2ApINeVPx6SVr5NQLNjzISaHyu9V+Apn+un7ZUjUOOLwCqtEieK8pz4wDfhdghM
p6YYAFAVNtTqOABx0MkyAyEF1HB46SxFWhm3W3EeKfpyLMiwrInc0+u/ThDbTeWlRe
4buN6MhZayrJEwPjzmiXzon3SgJZHwZtycmgZRf9c0w3F7LauUxPeSVsRPvKLxHpZ/
wdrWV44Y9IxycGPpndKR5EXFLwYgDUdHdoTH+aAPS7r/oWGtVOXoETXbJvM0VqdG4w
AdDySXjwPzTZA==
Received: from alfajor (unknown [45.44.229.252])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2B4C112046C;
Fri, 5 May 2023 14:27:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <831qjuisa4.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 05 May
2023 20:48:03 +0300")
Message-ID: <jwvednueixo.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN>
<831qjvjmw5.fsf@HIDDEN>
<48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN>
<83v8h7hxlj.fsf@HIDDEN>
<38c89611-a929-1869-e70d-983bd7edad14@HIDDEN>
<83jzxnhv2o.fsf@HIDDEN>
<59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN>
<83354aixqy.fsf@HIDDEN>
<3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN>
<831qjuisa4.fsf@HIDDEN>
Date: Fri, 05 May 2023 14:26:56 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.058 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
acm@HIDDEN, Max Nikulin <manikulin@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> If you want to find them, you will have to write the code to detect
> those dependencies, and then look at the graph produced from them.
> There's no other way (unless Stefan happens to remember some by
> heart, by some luck).
I think looking for calls to `provide` that are not at the end of files
is a good first step to finding the obvious ones (if my memory serves,
viper and ediff are two examples in Emacs's own code. The problem is
more common outside of Emacs because apparently fewer janitors roam
those realms).
Of course, the early files provide many other examples where we "solve"
the dependencies by hand to get things to bootstrap.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 5 May 2023 18:17:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 14:17:51 2023
Received: from localhost ([127.0.0.1]:57454 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pv006-0002nB-Ru
for submit <at> debbugs.gnu.org; Fri, 05 May 2023 14:17:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8748)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pv005-0002my-4z
for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 14:17:49 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7C310100485;
Fri, 5 May 2023 14:17:43 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E60EC1000B9;
Fri, 5 May 2023 14:17:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683310661;
bh=BSqsn4eBKZgnVnBO5G2/n9gnZ0dTMkPw16mZYnyaWug=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=j1HQ9rqcRe0OBu8xObM8omZ1YCmX6o0lOg/1dYRAiKW5Fkhf92Jboe2GnHHdVEX0F
7ReqEGAR7s+K0UlI/0oAmzEZEmoBJy6wBT8KNlz1oH76L3c/IuF7f8QQeki+uNc43d
swprraUPpIzljEesfceKTXWN2pBi1RdRxkM2C5jihomOgZMPNvZuoEjnjfZ7CpLUB4
BcvALDCHq5OH6VJwBFlxsxy0Afg+idXNeqTyyj6XaBW/9CHxRnHcEf/nEz0xMm3nuO
oPuHXW65TQiVr8/9n/H9VGs7AVXPBHdLc1um9a516W2d/Sr/oWEkFgTFP7sx6Cd0aQ
Sht3IprK3R0Nw==
Received: from alfajor (unknown [45.44.229.252])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ACE381208E2;
Fri, 5 May 2023 14:17:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> (Max Nikulin's
message of "Fri, 5 May 2023 23:37:36 +0700")
Message-ID: <jwvo7myejmd.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
<jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
<jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
<e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN>
Date: Fri, 05 May 2023 14:17:40 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.058 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> I have no ideas how to make `org-assert-version' better.
`my-require-with-shadow-check' is a suggestion to make it better.
And this sub-thread of the bug report was presumably your answer to the
question by Ihor:
Max, do you see any obvious downsides in Stefan's idea about consulting
`load-history' vs. `load-path'?
So are you saying that you don't think it's better?
If so, do you also think it's worse, and if so, in which respect?
> I had a hope that dependency generation may solve compiling issue,
It won't solve the mixed-version problem.
Incremental recompilation (i.e. `git pull; make`) is a qualitatively
different problem from the mixed-version problem, and by now, I'm pretty
much convinced that there just isn't a solution that fixes both: they
may look somewhat similar from a distance, but they're fundamentally
quite different.
Currently `org-assert-version` has no effect for `git pull; make` in
Emacs sources, so it's presumably focused on the mixed-version problem.
And I think that for this problem `my-require-with-shadow-check' is
a better check (e.g. it will also work when none of the files are
compiled).
> but I can not figure out what sort of circular dependencies is
> troublesome. I just must believe you and Eli.
I'll refrain from discussing this here. Incremental recompilation
problems should be discussed in another bug report, IMO.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 17:47:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 13:47:22 2023 Received: from localhost ([127.0.0.1]:57385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puzWb-0007qE-No for submit <at> debbugs.gnu.org; Fri, 05 May 2023 13:47:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1puzWW-0007px-KM for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 13:47:20 -0400 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 <eliz@HIDDEN>) id 1puzWQ-0002Vh-FQ; Fri, 05 May 2023 13:47:10 -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=oFw8AgufqCbN8Vz9ACk58BWGrXw/C+VkVkC3/eefga4=; b=DWFQR2xj9BGZ rpcEO7h2TVl0oobCwiRzfGgI0po30jq1/Dl7qjwbWMf9cCjynzcLrDri/y9wwyNE0wOZNRWRvHiNX b6fWQPnqEktOQzy4FdqY8dNQlhoo/wtzcqxIf11TBPIJ5pi++e/sO9ZuRWgdFIgh3OajdEBBjl0jL n0YF6pv+JKMx2Pel4oR3VcTqTBcR6uFcH4wloaMlVdchrbwFV14aUms2Ljlz6S8ZFuOvEK5r5JFBw S+IwC9MzlSPWZLYDduY9/oNFUz/c3CmW4qOiJC3lOdVKruYbmz3ARXnCry3FSK/Kpn/OY3Q3ZAJfb IAyf37NyEjXw0TTNLTeA9g==; 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 <eliz@HIDDEN>) id 1puzWP-0000WM-Sc; Fri, 05 May 2023 13:47:10 -0400 Date: Fri, 05 May 2023 20:48:03 +0300 Message-Id: <831qjuisa4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> (message from Max Nikulin on Fri, 5 May 2023 23:46:36 +0700) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 5 May 2023 23:46:36 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > > . require > > . eval-when-compile > > . eval-and-compile > > I was aware of these forms before you mentioned them first time in this > discussion. > > > etc. When fileA.el does any of that to load fileB.el, and fileB.el > > does something to load fileA.el (whether directly or indirectly, via > > other files), you have a circular dependency. > > I am sorry, but it is far from a complete example. I still have no idea > how to combine it in a such way that there would be no problem to > compile and load files, but attempt to create build dependencies would > fail due to a cycle. > > Perhaps editing some Emacs files you will notice the pattern you are > writing about. I will be grateful if you provide names of files > demonstrating cyclic dependency issue. You seem to think it's easy to find these examples and provide them, and I just stubbornly refuse to reveal them to you? It isn't easy. You need to actively find these references and chase their chains, to find those cases. I just know they exist because I bumped into them in the past. If you want to find them, you will have to write the code to detect those dependencies, and then look at the graph produced from them. There's no other way (unless Stefan happens to remember some by heart, by some luck).
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 16:46:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 12:46:49 2023 Received: from localhost ([127.0.0.1]:57326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puya1-00063H-0e for submit <at> debbugs.gnu.org; Fri, 05 May 2023 12:46:49 -0400 Received: from mail-lj1-f169.google.com ([209.85.208.169]:54527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1puyZw-000631-A9 for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 12:46:47 -0400 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2ac89e6a5a1so9552951fa.0 for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 09:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683305198; x=1685897198; 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=OC0Gzkwf2l5BY0fZetNCdGEvOJ42noq0DZpok08WDaU=; b=FQYKvtiUQmoYV857+uCRavHHLMzuFgbv+uljpE8ezC2LP82dwKk2cowc+Sq7yN1do2 rYo1xCFInDgsmpXO+V1Olc/5nLjr7WaxHzo4y59GAvjI5XkHPY5c8J4IEkktcx4HqaWE A1in1TZnwacbU9g9xLLvxerVCmukugKg1DpnZkqdHD2GMrMYE0d1fwHAPi4AqqOkRXfr pNZoOxpexZPPOhtUhTTzkT4qhQ9aCi+8FUhYDR3Qnkc57kpSEHuWLupjTeMP05ROsp1N ucl1/0o15m7qYeiUZiaII2C9ZuRwPleEibfDbSdE+EnZ7YVVNXbooNDfF2POtdNd2JdI Q5nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683305198; x=1685897198; 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=OC0Gzkwf2l5BY0fZetNCdGEvOJ42noq0DZpok08WDaU=; b=MGy1b5bfH1lv4gSYGRYBjjQdSAFQP7bdPFLRm/shgmg3ZNZ2cfeXIm6Du3DwtxSHNP aLJ8LrqqdW7FASpu93A+1s2ZciWATPjoq7Vaf2bjqQnPlRuQNCtGod+jlpyJCQQCVUvW kPdLb9FSZyG52C5yQf+39wpT8226y5PcDWlrm46JcxKhxVDiO+IEevvQTUFcKzAJkzih jwywu3NehqrSUYZhJSxtcYhK8Sa8XNA4hmlsfVO/LBHNvdmQc1A53FOhUj9bcTUNXw8z aIJ8D/DX4FSq3xyECpiSd8do+s35NvuluijqbMXY6Hk3wQ3uFDyulyDUYGd6gGYXyYVc p3Tw== X-Gm-Message-State: AC+VfDxBDGdXU2Qzgq/K/3Iz6lNlWMI5tbM+PyyicsdC1uh4nW45MCg3 9exj41wD03NSGSjwdkk1a7aihOCOxjKo0g== X-Google-Smtp-Source: ACHHUZ6Ithx+QmRsBykvNq58O74MbxFXjmrE6nDvdxVk8hdzVUnZTickpZrPMPqmQNDyn/XlA+kBcg== X-Received: by 2002:a2e:8502:0:b0:2ac:7137:5f13 with SMTP id j2-20020a2e8502000000b002ac71375f13mr563122lji.9.1683305198242; Fri, 05 May 2023 09:46:38 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id a14-20020a2e860e000000b002a8ecae9567sm33698lji.84.2023.05.05.09.46.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 09:46:37 -0700 (PDT) Message-ID: <3ce7d18d-8190-a379-f503-5b0fef1dcb88@HIDDEN> Date: Fri, 5 May 2023 23:46:36 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> <83354aixqy.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83354aixqy.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 05/05/2023 22:49, Eli Zaretskii wrote: > You should look for all the ways we load one Lisp file from another: > > . require > . eval-when-compile > . eval-and-compile I was aware of these forms before you mentioned them first time in this discussion. > etc. When fileA.el does any of that to load fileB.el, and fileB.el > does something to load fileA.el (whether directly or indirectly, via > other files), you have a circular dependency. I am sorry, but it is far from a complete example. I still have no idea how to combine it in a such way that there would be no problem to compile and load files, but attempt to create build dependencies would fail due to a cycle. Perhaps editing some Emacs files you will notice the pattern you are writing about. I will be grateful if you provide names of files demonstrating cyclic dependency issue.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 16:37:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 12:37:51 2023 Received: from localhost ([127.0.0.1]:57322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puyRK-0005pr-SL for submit <at> debbugs.gnu.org; Fri, 05 May 2023 12:37:51 -0400 Received: from mail-lf1-f49.google.com ([209.85.167.49]:60497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1puyRF-0005pY-Ah for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 12:37:49 -0400 Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-4efe8991bafso2338073e87.0 for <62762 <at> 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) 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) Message-ID: <e2b483b0-ddb9-ebc8-9df5-b32ff3c1d20e@HIDDEN> Date: Fri, 5 May 2023 23:37:36 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <jwv5y96ub39.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) 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.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 15:49:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 11:49:18 2023 Received: from localhost ([127.0.0.1]:57306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puxgL-0004Sg-G7 for submit <at> debbugs.gnu.org; Fri, 05 May 2023 11:49:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1puxgH-0004SR-PT for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 11:49:15 -0400 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 <eliz@HIDDEN>) id 1puxgA-0006mW-1r; Fri, 05 May 2023 11:49:06 -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=xGVX9z/Xvcucmi73NjVanBPYlvW6KAOmdiyM3Zav4GQ=; b=ZJMY2lGtm3kp G6U95eiUgBM94wCNYJGATNgfASqpzTrIjJVt/ZDXL/i2Vhg3UBcHwWQtkrkpYJCJL++AsGnyJJOe0 FXvd9eWksorAhbwdkakJc5CZ4yssztwWIflRVc+w3NIbf2lE+TwIaH3Drh/vXGmtfNo4c39FN0Kl6 a8S+Nh/YyFs0jcNzT02o8214GutAxQ/Fyrl2qfD9guyMSFQIvmbXY/k2ZlYK+oq7MUsP3jxPFmnLm Weudc/d7fg1YxoySqchQFPweag39M+L2Nmw4+NHsN/qp4fugRHZMSfDHs994qLXQmhPLML1MPdGtD 0zbxT0VRh4sIDbhb89DrzA==; 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 <eliz@HIDDEN>) id 1puxg9-0003Mw-HN; Fri, 05 May 2023 11:49:05 -0400 Date: Fri, 05 May 2023 18:49:57 +0300 Message-Id: <83354aixqy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> (message from Max Nikulin on Fri, 5 May 2023 22:33:48 +0700) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 5 May 2023 22:33:48 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 05/05/2023 18:33, Eli Zaretskii wrote: > >> Date: Fri, 5 May 2023 18:20:09 +0700 From: Max Nikulin > >> On 05/05/2023 17:38, Eli Zaretskii wrote: > >>>>> This doesn't work in Emacs, in general, due to circular dependencies. > > Eli, I am still unable to associate this with particular cases of elisp > code or with how it is split over several files. That is why I am again > asking for examples illustrating issues you have in mind. > > >>> What do you mean by "unavoidable"? > >> > >> Max Nikulin Fri, 5 May 2023 11:18:17 +0700 > >>> 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. > > > > If it's this part, then I don't see how it can be relevant to our > > case: our problem is to teach Make about these dependencies, not to > > teach a Lisp compiler about them. > > I can not figure out which kind of cyclic dependencies may cause > troubles with dependency generation, but I had a hope that it would be > possible to reorganize code to avoid such kind of dependencies. > > > I don't have ready examples off the top of my head, sorry. You have > > the Emacs Lisp sources, so you have all the information, and can find > > those circular dependencies yourself if you don't believe me and > > Stefan. > > It might be even better if you will provide a brief example unrelated to > real Emacs code. I have no idea which code I should search for. You should look for all the ways we load one Lisp file from another: . require . eval-when-compile . eval-and-compile etc. When fileA.el does any of that to load fileB.el, and fileB.el does something to load fileA.el (whether directly or indirectly, via other files), you have a circular dependency.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 15:34:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 11:34:01 2023 Received: from localhost ([127.0.0.1]:57300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puxRY-00040f-V9 for submit <at> debbugs.gnu.org; Fri, 05 May 2023 11:34:01 -0400 Received: from mail-lf1-f44.google.com ([209.85.167.44]:62686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1puxRV-00040M-Ub for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 11:33:59 -0400 Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-4f139de8cefso15843015e87.0 for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 08:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683300832; x=1685892832; 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=HMk8gqmvIFqdl2EKX68jAuTRwdBPIOIWlwA0momMtgM=; b=i58HHVx+T28vS28mhXFDmshJVLSJ2e+54S7Ez/9vo395ylU35XQKKVjPk2LzMrOEyo 5AL/Ncyh4SmdtpTqnACJs5u8g/H2TxQ+p42PiqjKVzfN9vMAz1Mggi63Tn+WkJQYqnwg +4AtzLcOXsxIVP6Vzh+fKDgGfR+93JOWrLRkfRHBgxrHsodzmyIY/oGBwro3+ZRYPbym wxLg1uihxpcaaoQyX1juEpaBnnZ4NdR589Z288f8Tnn7aSPhA+n55tb6v+hZPVx5OlwL 2d2H2shZd6njAia34UmI4uG5lpsGQDgpV1KDFFoZgQyJ8u5+jBWN75RnNek3aRn1X51c Cytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683300832; x=1685892832; 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=HMk8gqmvIFqdl2EKX68jAuTRwdBPIOIWlwA0momMtgM=; b=UOKPN2uAHk1LHSFW5ih/K+REZ0SuwnU2KBAyvcxGAH8OJWmTTuHtrkLIFghDxK5b/3 EU+G991BLmFjiBF4U3HjHiKio2wBvOAzj3hPiU21cAgUWvy1O0ELnC9Smr6UxfozGTr1 g4tCz88HV6GWr/6Dv70R4/W32lax0EvVvSp4OA7zuk61TuwOUwwlOo34yJnjLaEao5tG mu2asdA8yg6PnMgNxjFK8OHroP4DLPPl4To47+pXJRGnWdKUMmyX6iqFs6/42TIl0MkH Btw1Mltbbfuo9+reNYnquSQBjCg3LBxcI3WtoraTcfN+RE11vf4GQaOSxbAEf0pA3HvM 4pjg== X-Gm-Message-State: AC+VfDy7E5KuEx1KA5qZAvE4URjuZUVtSDqG6LZ0f6OTP0Lw+uxmDO6D C71SEy63ZjJwaFabuW8BvJA= X-Google-Smtp-Source: ACHHUZ5uFMWqZZo/QiRon7h/g6N3xXAx5VBxN1KZdKPAkYsMhxJFKF2ej9rJVR5LX35/SuhrQ+piFg== X-Received: by 2002:a05:6512:983:b0:4f1:4074:b4fd with SMTP id w3-20020a056512098300b004f14074b4fdmr678847lft.29.1683300831464; Fri, 05 May 2023 08:33:51 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id d24-20020ac24c98000000b004eafabb4dc1sm327156lfl.250.2023.05.05.08.33.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 08:33:51 -0700 (PDT) Message-ID: <59ccf87f-effb-2168-2c17-34d950060b1b@HIDDEN> Date: Fri, 5 May 2023 22:33:48 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> <83jzxnhv2o.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83jzxnhv2o.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 05/05/2023 18:33, Eli Zaretskii wrote: >> Date: Fri, 5 May 2023 18:20:09 +0700 From: Max Nikulin >> On 05/05/2023 17:38, Eli Zaretskii wrote: >>>>> This doesn't work in Emacs, in general, due to circular dependencies. Eli, I am still unable to associate this with particular cases of elisp code or with how it is split over several files. That is why I am again asking for examples illustrating issues you have in mind. >>> What do you mean by "unavoidable"? >> >> Max Nikulin Fri, 5 May 2023 11:18:17 +0700 >>> 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. > > If it's this part, then I don't see how it can be relevant to our > case: our problem is to teach Make about these dependencies, not to > teach a Lisp compiler about them. I can not figure out which kind of cyclic dependencies may cause troubles with dependency generation, but I had a hope that it would be possible to reorganize code to avoid such kind of dependencies. > I don't have ready examples off the top of my head, sorry. You have > the Emacs Lisp sources, so you have all the information, and can find > those circular dependencies yourself if you don't believe me and > Stefan. It might be even better if you will provide a brief example unrelated to real Emacs code. I have no idea which code I should search for.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 5 May 2023 14:29:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 10:29:19 2023
Received: from localhost ([127.0.0.1]:57216 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1puwQx-0008IK-EE
for submit <at> debbugs.gnu.org; Fri, 05 May 2023 10:29:19 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40088)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1puwQv-0008I6-1S
for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 10:29:18 -0400
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)
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==
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)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> (Max Nikulin's
message of "Fri, 5 May 2023 11:18:17 +0700")
Message-ID: <jwv5y96ub39.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
<jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
<6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
Date: Fri, 05 May 2023 10:29:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.119 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
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
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 11:32:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 07:32:25 2023 Received: from localhost ([127.0.0.1]:53285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1putfk-0007ws-SV for submit <at> debbugs.gnu.org; Fri, 05 May 2023 07:32:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1putfe-0007wO-8M for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 07:32:22 -0400 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 <eliz@HIDDEN>) id 1putfX-0000BC-MX; Fri, 05 May 2023 07:32:11 -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=I6ZV2v3AUcD1LFnUt5wh4NmNc6QSu5JKKNlN5rZdpHg=; b=g1eeZ6YnbKDw QGsjwe6642CqsM43GcHSukesOT8CU1yJCVYCUrVQN2qjJM1N9i90ZXubrkIeLmFi+q9qpQrLTicrW DEB6/2lfRXAfXXUuLhI3hh11g/Y/V/XABWXqdRR1Kq8Wt6C6cpfxGSn1BwDKYyI0uTGJnYZhsRvTJ xtMhPbwerEKgTtUJXV9HvOrWucS/6va7ypXgAN6gFRshzo0DPxq6McJE+wjIo++4/Guc6HYVkWL3V ClCMib9xloFtxNRp9alZBCOHtL8FNV5N0UCD/G6uhsRShUipHDk0LNo2XmedM44epHA/Mz0JJNrOy skBeoGgW4UMmCSJZm4z5Uw==; 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 <eliz@HIDDEN>) id 1putfX-0005Kz-3d; Fri, 05 May 2023 07:32:11 -0400 Date: Fri, 05 May 2023 14:33:03 +0300 Message-Id: <83jzxnhv2o.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> (message from Max Nikulin on Fri, 5 May 2023 18:20:09 +0700) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 5 May 2023 18:20:09 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 05/05/2023 17:38, Eli Zaretskii wrote: > >>> This doesn't work in Emacs, in general, due to circular dependencies. > >> > >> Could you, please, provide an example where circular dependencies are > >> unavoidable or cost of disentangling of mutual dependencies is prohibitive? > > > > What do you mean by "unavoidable"? > > Ones that do not allow to apply approaches like: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#140 That's a huge message. Which part of it specifically? > Max Nikulin Fri, 5 May 2023 11:18:17 +0700 > > 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. If it's this part, then I don't see how it can be relevant to our case: our problem is to teach Make about these dependencies, not to teach a Lisp compiler about them. So forward declarations don't help here, because Make doesn't have any such declarations, and it figures out dependencies on its own, given only the prerequisites specified for targets. > On 05/05/2023 17:38, Eli Zaretskii wrote: > >> My general impression that behavior of code having circular dependencies > >> is harder to comprehend. > > > > AFAIR, the problem is that we use 'require', eval-when-compile etc. to > > get definitions of macros, functions, and variables. There's nothing > > difficult to comprehend in this. > > I still have no idea which way it may be related to determining of order > of compilation based on dependency tree. That is why I asked for > particular examples. I don't have ready examples off the top of my head, sorry. You have the Emacs Lisp sources, so you have all the information, and can find those circular dependencies yourself if you don't believe me and Stefan.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 11:20:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 07:20:19 2023 Received: from localhost ([127.0.0.1]:53268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1putU3-0005BF-IP for submit <at> debbugs.gnu.org; Fri, 05 May 2023 07:20:19 -0400 Received: from mail-lf1-f52.google.com ([209.85.167.52]:49239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1putU2-0005Ay-9c for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 07:20:18 -0400 Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-4efe8b3f3f7so1899675e87.2 for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 04:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683285612; x=1685877612; 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=MnxWzjJoaD6FEKRI5VFviFa4NTTVbHDh5gT0Ayl3XmU=; b=Jsk+DPqbGtrHSxSRLxSmgdQxVsuoT9yll2A1LQatQhXGjEGkv7PsJG6SOFAz9DmUXJ RX2e7/DlEwBgKL9NLJMZEg03quSByTiWdmW2Kg40ijY9F50f9iYj6Anwk0RVeUz6yPzH 92Mjyg+VvS3AoPDBBXa3eET2hnN5zHY457BOQKsRx2292/Mo80TH/9GMMYxuB8srEllO wo7DtRoa1jb13wqv96Ddn+fbPlf9IaWlRjYIvdDfcROr2h6QwHVYQG5TOFjpKR65o7Y6 Kmzewify2axYI+0VVp12PVUdWX2LXasWPwOFmB6K3GCK/2tD0FMUTtAlmC31MgM+Qnut UWZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683285612; x=1685877612; 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=MnxWzjJoaD6FEKRI5VFviFa4NTTVbHDh5gT0Ayl3XmU=; b=b7rBZhLtySvCatbbA9IagAbeo4NtZWCUqfGYrjpY1kNCA9atzg1nF/IXAL6FKMzJEU uZUopXflcE/BrWyWttK+fEZlbjrbvj+kmFBpUxkZ/ALmx7Zj9CtsUdX7dkXPPm9OJd6d Y1TfEe875LBeUlWmmKwoF+WBHLYmFHInZYlDxB4TjwBVGUEN+yaeE5wzx5va+BlVpxHm embpj5jMCvQK3X7mVTOamJOSiXwRERQzS+JUZi69dn/cXyJud8mv6aylpwyAzzYmwWzl l/wrC1rPAJXJRggvXJSn5jLzdZhzYNlYjno4UbW2r4twC1X88liBgK722olRNC1FARHp aC5A== X-Gm-Message-State: AC+VfDyg+n93o6ORtxbYP+3OjKV15Xhvw3N80LepaM4m95VSV2uV8dzI 4lODdNncLrf5LU9E0OFhwAKciWzsSBjynA== X-Google-Smtp-Source: ACHHUZ6DGb6H5i3SeRSxjpgYfPqHcBz5PcuY1dkjVsR8Swr8fkOgetGnFP5ZVDt69XczrML3ACQbug== X-Received: by 2002:a2e:920d:0:b0:2a8:baab:fb2e with SMTP id k13-20020a2e920d000000b002a8baabfb2emr299980ljg.47.1683285611843; Fri, 05 May 2023 04:20:11 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id l18-20020a2e9092000000b002a8c7c5d64dsm288322ljg.1.2023.05.05.04.20.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 04:20:11 -0700 (PDT) Message-ID: <38c89611-a929-1869-e70d-983bd7edad14@HIDDEN> Date: Fri, 5 May 2023 18:20:09 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> <83v8h7hxlj.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <83v8h7hxlj.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 05/05/2023 17:38, Eli Zaretskii wrote: >> Date: Fri, 5 May 2023 14:27:29 +0700 From: Max Nikulin >> >> On 05/05/2023 13:46, Eli Zaretskii wrote: >>> Date: Fri, 5 May 2023 12:27:25 +0700 From: Max Nikulin >>>> The robust way is to define compilation order through dependencies, >>>> preferably autogenerated ones). >> >>> This doesn't work in Emacs, in general, due to circular dependencies. >> >> Could you, please, provide an example where circular dependencies are >> unavoidable or cost of disentangling of mutual dependencies is prohibitive? > > What do you mean by "unavoidable"? Ones that do not allow to apply approaches like: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#140 Max Nikulin Fri, 5 May 2023 11:18:17 +0700 > 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. On 05/05/2023 17:38, Eli Zaretskii wrote: >> My general impression that behavior of code having circular dependencies >> is harder to comprehend. > > AFAIR, the problem is that we use 'require', eval-when-compile etc. to > get definitions of macros, functions, and variables. There's nothing > difficult to comprehend in this. I still have no idea which way it may be related to determining of order of compilation based on dependency tree. That is why I asked for particular examples.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 10:37:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 06:37:51 2023 Received: from localhost ([127.0.0.1]:53215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pusox-0001O7-7u for submit <at> debbugs.gnu.org; Fri, 05 May 2023 06:37:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pusot-0001Np-Ix for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 06:37:50 -0400 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 <eliz@HIDDEN>) id 1pusom-0004vs-LA; Fri, 05 May 2023 06:37:40 -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=rByXTsivnmQiPhOSMKCPyBzKH2N9IVklWQL09xc3AVg=; b=e4ZhcgpqAYab fIbSqVeoP7G5mHQhah4pwdyWKS+PR7Y32qHC3qtHroUTHmWgcyYwuNk2p/2Z6hmrhQUAupyPcsBJC /PfX8T1FKFtrJbv1UY2duRH+ODJEAnI80aOvbf41Q6nBSOFoS3MQQrqiGzl+TIjxo2908Fw2+kffN wOIctcLRpXC7ahOVTXt1rG85s9gazeXrS6zviSL/qw+ZNlrPnH2aZLo1egwDTbbVS/5DATSDCqb9V n+T7lbutoNTWV7E+7QN9OQ9wtfVRqAAgqgVNSfNi9fbSeV5Wt+Xn6VpMR2BzpahLHEmkSG6wh+5PR Dy57J5NjFxCbhYv7K5yblg==; 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 <eliz@HIDDEN>) id 1pusom-0001J3-3K; Fri, 05 May 2023 06:37:40 -0400 Date: Fri, 05 May 2023 13:38:32 +0300 Message-Id: <83v8h7hxlj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> (message from Max Nikulin on Fri, 5 May 2023 14:27:29 +0700) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 5 May 2023 14:27:29 +0700 > Cc: monnier@HIDDEN, yantar92@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, acm@HIDDEN > From: Max Nikulin <manikulin@HIDDEN> > > On 05/05/2023 13:46, Eli Zaretskii wrote: > > Date: Fri, 5 May 2023 12:27:25 +0700 From: Max Nikulin > >> The robust way is to define compilation order through dependencies, > >> preferably autogenerated ones). > > > This doesn't work in Emacs, in general, due to circular dependencies. > > Could you, please, provide an example where circular dependencies are > unavoidable or cost of disentangling of mutual dependencies is prohibitive? What do you mean by "unavoidable"? > My general impression that behavior of code having circular dependencies > is harder to comprehend. AFAIR, the problem is that we use 'require', eval-when-compile etc. to get definitions of macros, functions, and variables. There's nothing difficult to comprehend in this.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 07:27:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 03:27:39 2023 Received: from localhost ([127.0.0.1]:53087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pupqt-0001VC-HM for submit <at> debbugs.gnu.org; Fri, 05 May 2023 03:27:39 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:62968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1pupqs-0001Uv-CC for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 03:27:38 -0400 Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-4f00d41df22so14479752e87.1 for <62762 <at> debbugs.gnu.org>; Fri, 05 May 2023 00:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683271652; x=1685863652; 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=hVX74vMoqALHZRzYG3KgZqK3YQXuBQiLtR/T41toPKE=; b=Dy/e469ZOROqpkN5iX0TNv8Im+Qvz2jXn8S8BT6SaHB7K27ug8uXYUU2UvU7t4Dd9h byWgQVXKQlNRb3zvbjODwhbrL34WcV5moIYLmiMb2uR7/ViOmpFXHeEd6I6/mig9ANcg KQGQUYqRfc9HusfMBkMbFHoQCDWFIQmrsrLzl6C7pYlFkzVGSADeqQekA20N/qIoxN4P gxQKQZj/0u0MJgNR+qGN2y62RV1VwotrgYI8/7kYI3lzuEkOrMEeW64Y8IFYj++laJki ZotZaIC9tLXrIeMduupijKfzlUD+0HjqgyZDwXqeWeD0aV5Uz+vrpIjUdCm2xyTLubBJ zd7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683271652; x=1685863652; 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=hVX74vMoqALHZRzYG3KgZqK3YQXuBQiLtR/T41toPKE=; b=KKzscGOujKhQGrsyxV6G3nuR6u1Mubdo4Xtk2bSeoWa8hOQn6j+Q++V9i2Mp2wTjaa r1ikkiMtrN73GkvXTRvCcD6kvh+gOvWDpT8vFsz24UWzFWQYWk1O12dggCnEJt/GoRDi AzsDM/R12PD0virVBC0AbB0SinRAA6+0rlbmQiY0MBHs0XZ7qaB81z3e4PwNBaN/TXs1 7F09wYd4fGNaOIuL/e6cJuJ7vKuwxUlP1eJ2Lv9cEm8l9akcwE74J4a1pJZp1uIAMk15 4+dKt7uWde8bTzb0WrltsgIaTmby1Y8xz5aiszdUwZDFNBg2Xl9m/vQMgObGJHByhoOn aVNg== X-Gm-Message-State: AC+VfDzWSuStb3zuW1wzw3ob2IyU869I3RE17mb04S0phuq2ujcBLiGk 78T+zF7F93zPBhEL0ZKTYdEpkl5+dqPTRQ== X-Google-Smtp-Source: ACHHUZ4UmrPKFa6MlF8F4PAbTDaMbBDEg3U5HmUHvy3TunTfDfys/bhTf4+BoRfKHcYQDu91mhrSDQ== X-Received: by 2002:a05:651c:483:b0:2a8:e46b:9410 with SMTP id s3-20020a05651c048300b002a8e46b9410mr441236ljc.15.1683271651971; Fri, 05 May 2023 00:27:31 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id o7-20020a2e9447000000b002ac7469b22csm206694ljh.57.2023.05.05.00.27.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 00:27:31 -0700 (PDT) Message-ID: <48f15926-d002-877b-1d01-3a607fe42b76@HIDDEN> Date: Fri, 5 May 2023 14:27:29 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> <831qjvjmw5.fsf@HIDDEN> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <831qjvjmw5.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 05/05/2023 13:46, Eli Zaretskii wrote: > Date: Fri, 5 May 2023 12:27:25 +0700 From: Max Nikulin >> The robust way is to define compilation order through dependencies, >> preferably autogenerated ones). > This doesn't work in Emacs, in general, due to circular dependencies. Could you, please, provide an example where circular dependencies are unavoidable or cost of disentangling of mutual dependencies is prohibitive? My general impression that behavior of code having circular dependencies is harder to comprehend.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 06:46:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 02:46:06 2023 Received: from localhost ([127.0.0.1]:53011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pupCg-0008Ni-5g for submit <at> debbugs.gnu.org; Fri, 05 May 2023 02:46:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pupCe-0008Mw-Sb for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 02:46:05 -0400 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 <eliz@HIDDEN>) id 1pupCY-0000z5-FC; Fri, 05 May 2023 02:45:58 -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=xvR40sWySTj+4/nNqzCcquFthjn2W/a0B89berPCqHk=; b=kjkvJkURb65w KJUIPPyAP/SKlYShK/mn5uQW7hhrIr8nCBSoDdDxnarnLstiwcdtDXgZ3eBKfJHPyY/QqTmelSWkp VEcN6HUDKrfoiVWNjDRjZu5ECF0VklvXmRhSUDgYEyjK+8JRqS7Cbg/YOT6EjdiReG88ccrCqu4hS 5OGb+aAmuYtN/hc52xMMATCkx+G3TNXWpowFfbAj2qTzAJgJCgKhthA2aE57l4C9BOEMA7DnR4V5h Riww6/0kt6E0FSzMNUmZCATNAw9WCXAzkBSezAttJbxVhrKvBOHcQsR6Li1NHFpChfegTwnFregms mRMDFpSNvePlNWefhDEG0Q==; 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 <eliz@HIDDEN>) id 1pupCX-0000k0-U1; Fri, 05 May 2023 02:45:58 -0400 Date: Fri, 05 May 2023 09:46:50 +0300 Message-Id: <831qjvjmw5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> (message from Max Nikulin on Fri, 5 May 2023 12:27:25 +0700) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 5 May 2023 12:27:25 +0700 > From: Max Nikulin <manikulin@HIDDEN> > Cc: Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, > Alan Mackenzie <acm@HIDDEN> > > I have realized that neither `load-prefer-newer' not checking hash of > the source .el file can help per se when an .elc file becomes stale due > to update of a macro in a require'd file. Yes. > The robust way is to define compilation order through dependencies, > preferably autogenerated ones). This doesn't work in Emacs, in general, due to circular dependencies. > An alternative is to hope that usually it does not hurt and you are > ready to remove .elc files (e.g. by make bootstrap) when you faced > an apparent error or just suspect mixed version compilation as the > cause of noticed strange behavior (I named this broken incremental > builds). That's what we have been doing for ages, and it generally works well.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 5 May 2023 05:27:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 01:27:38 2023 Received: from localhost ([127.0.0.1]:52882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1punyk-00037I-Gl for submit <at> debbugs.gnu.org; Fri, 05 May 2023 01:27:38 -0400 Received: from mail-lf1-f41.google.com ([209.85.167.41]:44417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1punyh-000371-BP for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 01:27:36 -0400 Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4efd6e26585so1545205e87.1 for <62762 <at> debbugs.gnu.org>; Thu, 04 May 2023 22:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683264448; x=1685856448; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=K+MVJVJYsa1DnWIA6xynlIUsoaeMhIxvqj/vpDhZNGo=; b=FVZuAvLBczeQbPjGeHE+tZAPpehtbaahkRzHWmDjR6w25ENOUDNZW/mNktP7SrOH7W ayUlc0pAl+XdchMcdwGt6iBgNGoaHLRdn2PcnUsvrukExdhg5rk5gZK+8G4QCMcmaHr9 CU4mp9ivb0D6hCYPCGetSuRW8+fW6NqIEoq79jsUOVhx/LN+LjWZhMF6IvT/OYPiyhBX MIPVta41bMBstHN6c5uqknMt8YccP9Y49k0P+eSP+s4Ls3BIjubG4gRnybl7PH0ICYfq ZCb2zvRyW7e78bxdAhBUh6rYlKomjkBvltZ14mxT54B7VrcTvDTfoiOaIC6KnEfKT2nk dxjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683264448; x=1685856448; h=content-transfer-encoding:in-reply-to:references:cc:to:from :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=K+MVJVJYsa1DnWIA6xynlIUsoaeMhIxvqj/vpDhZNGo=; b=YqtKrVLGj79ShtDKBpPRXgr5IcPeiI6iiNaPb2RrHp/dG9zil2bhq2B2dMoxs8e67F 0paoC66LcZfL/nKKERd6xxe+zNkoZZ0RgxN1tdFyBjJ3jXZ0s0vWcn4gIM6nHIZHFUyj hqyz9VComEcNISnMAHg0IquTCHmzwJXnUSvUQTE1YOt+mGZeIDqWcBXtoaTKQdGBT74O q9iU+BQWeW/MT4bpBMAdfFC298XLSWDG1a4uoA2F52VMdJxp/x6Z4ll74SJt2ba7AOff aOQjmazJiR/wSSAYXToYzM5eKREx9Y4rSqpVvIT6cBZz3UZrw1MXhVasWqdO+N/mHe+6 C+/Q== X-Gm-Message-State: AC+VfDxs0j1zkstVognqmAUQ8gHrXgd2Jf6LIBepaBj93FOabUUszfqF w7uXayFbgLdquL3sfjaIUqY= X-Google-Smtp-Source: ACHHUZ4KDXmBFvIvgsrWvddRxRzh4QxWwK/WuxL/nFDEYKPsb9NnNi1GAaCBSUrmngMjuNjwcWNZEQ== X-Received: by 2002:ac2:5443:0:b0:4eb:1527:e29d with SMTP id d3-20020ac25443000000b004eb1527e29dmr168818lfn.52.1683264448075; Thu, 04 May 2023 22:27:28 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id t21-20020ac243b5000000b004b4cbc942a3sm148269lfl.127.2023.05.04.22.27.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 May 2023 22:27:27 -0700 (PDT) Message-ID: <64a61548-e343-992f-d193-d8ff4fe0623b@HIDDEN> Date: Fri, 5 May 2023 12:27:25 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US From: Max Nikulin <manikulin@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> <jwvlei3st6i.fsf-monnier+emacs@HIDDEN> <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> In-Reply-To: <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On 05/05/2023 11:18, Max Nikulin wrote: > On 05/05/2023 04:53, Stefan Monnier wrote: >> Also, the use of `load-prefer-newer` in lisp/Makefile eliminates most of >> the brokenness we used to have in our incremental builds. > > `load-prefer-newer' is a kludge as well. E.g. Python people migrated > from comparison of timestamps to inscribing of .py file hash into byte > compiled .pyc files. So if the hash in .pyc does not match .py content > then .pyc file is recompiled or just ignored. I have realized that neither `load-prefer-newer' not checking hash of the source .el file can help per se when an .elc file becomes stale due to update of a macro in a require'd file. The robust way is to define compilation order through dependencies, preferably autogenerated ones). An alternative is to hope that usually it does not hurt and you are ready to remove .elc files (e.g. by make bootstrap) when you faced an apparent error or just suspect mixed version compilation as the cause of noticed strange behavior (I named this broken incremental builds).
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 5 May 2023 04:18:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 05 00:18:28 2023
Received: from localhost ([127.0.0.1]:52781 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pumtn-0000rn-TB
for submit <at> debbugs.gnu.org; Fri, 05 May 2023 00:18:28 -0400
Received: from mail-lf1-f46.google.com ([209.85.167.46]:56723)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <manikulin@HIDDEN>) id 1pumtl-0000rS-Rv
for 62762 <at> debbugs.gnu.org; Fri, 05 May 2023 00:18:26 -0400
Received: by mail-lf1-f46.google.com with SMTP id
2adb3069b0e04-4edc114c716so1489856e87.1
for <62762 <at> debbugs.gnu.org>; Thu, 04 May 2023 21:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683260300; x=1685852300;
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=SwR8kN6WtvVBfiJkKbaL0hFXbRWEHcFKsGp3opUIi+U=;
b=joYQXpHxkUu4DJB5G0a/kHnrW6knSmBqxuDzP16iOChAra6JHP5QqQU+xdFxH3aAK4
eJh1apH+wSxb5sa6g4Fs04TOsphLbYgm3mkbdy+SMf8GaUjTdTs7W2PoO2NRuls8kzyY
AhAf54Br3uKRH54Gio4Ujk6vTLbHYpnH81ud6DF9exImLNUHN4QxerNZK+Yw1mhco2Ce
9k2pDP5nkYtRGTrVnW7lgP9ALKJ/b5t4rNBFWs1HxxjxGcWzCmfJWK4Kpw1Qza+pR6Z/
DgCHQWzkCR/UKK3hrpmueYecVULMUQZRDLq6JWrSqJ66CVyzQyXCciXlem30ZyyZZoTY
H/ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683260300; x=1685852300;
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=SwR8kN6WtvVBfiJkKbaL0hFXbRWEHcFKsGp3opUIi+U=;
b=HtsxEQVtFVVqGLetN15NRR4ta6Di740efL6oaKeqm3Nu1Y2R5uzGUDadFZgFhndZB1
noqxVo3I9wNIo80e0RpumuFHyMdgDZ3fmiBzoa+qly+7gE5MFZA5XfLlYjh5BPYwjBG/
oYj+UPVmiTSr0vixjIVd0uD90N+zOVzeML+GsbWgqAhe/ioT1I/H3xRxpxHGO4qVE65l
xpWXUfNNQ96iAl1Vp9aRfk/CzGlLdYXZ7wPq4EYzftR2Gww8pjas+tPitBH0Q56dV787
L3f3CLVa7RTSi/j5o6I0Tsf0RYjfTUZdnRyrKbRk4bKCSvyg0x+5gKI5c9dTw0dGu/md
m1pg==
X-Gm-Message-State: AC+VfDyNi4+Bm9cUA3eFyOnNQzmvRmM5IQVK1sjyXwq00MAY2o/QKlSw
//g3nJG7oOK5RD134M287mY=
X-Google-Smtp-Source: ACHHUZ4NqIz5GYwwzTjkKPjQyegAZKJnk+aDKO+XV2n1410pHRtJ6tiWporylXfsBaZnHkOHuKi9Ng==
X-Received: by 2002:ac2:4902:0:b0:4b5:9b8f:cc82 with SMTP id
n2-20020ac24902000000b004b59b8fcc82mr148250lfi.0.1683260299364;
Thu, 04 May 2023 21:18:19 -0700 (PDT)
Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188])
by smtp.googlemail.com with ESMTPSA id
d24-20020ac24c98000000b004eafabb4dc1sm127604lfl.250.2023.05.04.21.18.18
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 04 May 2023 21:18:18 -0700 (PDT)
Message-ID: <6070e598-7dee-1b7a-7f97-26a90618cb7a@HIDDEN>
Date: Fri, 5 May 2023 11:18:17 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN>
<87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
<87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
<87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
<87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
<jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
From: Max Nikulin <manikulin@HIDDEN>
In-Reply-To: <jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
On 05/05/2023 04:53, Stefan Monnier wrote:
>> First of all, I think, incremental builds are broken in Emacs.
>
> Indeed, but in practice they usually work fine.
...
> Also, the use of `load-prefer-newer` in lisp/Makefile eliminates most of
> the brokenness we used to have in our incremental builds.
`load-prefer-newer' is a kludge as well. E.g. Python people migrated
from comparison of timestamps to inscribing of .py file hash into byte
compiled .pyc files. So if the hash in .pyc does not match .py content
then .pyc file is recompiled or just ignored.
By the way, `load-prefer-newer' make things even worse in the case of
`org-assert-version' when full dependency tree is not available. I have
tried to add dependency for all lisp/org/*.elc files on
lisp/org/org-macs.elc and lisp/org/org-version.el, but it is not enough.
During recompilation `require' prefers .elc files (.el files not
changed, so they are older) with inscribed stale `org-version' causing
compilation error. If .el files were loaded, recompiling would be
slower, but with up to date macro definitions. So in general, due to
`load-prefer-newer' the chance to get stale macro during incremental
build is higher than .el files are preferred. I admit, it is not common
case when definition of a macro depends on another macro loaded from
another file.
I am unsure if it is possible to express in make that all lisp/org/*.elc
files must be removed on change of
lisp/org/{org-version.el,org-macs.el}. It might alleviate the issue till
implementation of properly dependency tracking.
>> `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.
> 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' and just hides the issue with
dependencies for incremental builds.
>> gcc supports generation of dependency files as a side effect of
>> preprocessing for decades, see
> [...]
>> 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.
> 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.
>> Instead of dependency tracking Makefile in Emacs uses much more limited
>> approach with the main-first target.
>
> Hmm... no, `main-first` doesn't have much to do with dependencies (and
> things like deciding when to *re*compile a file), it's concerned with
> compile-time performance (typically for the first compilation, when the
> `.d` dependencies wouldn't be available yet).
My impression is that main-first defines order of compilation. In this
sense it servers for the same purpose as dependencies.
>> By the way, generated dependency map might help to properly reload a package
>> update without restarting of Emacs.
>
> BTW, I was reminded recently that `load-history` keeps track of
> `require`s so we already have most of that info at hand.
I agree that heuristics based on `load-history' mostly works, but I
suspect corner cases might exist. I have not inspected `org-reload'
closely and what Emacs core offers instead.
> The idea was to check the shadowing only for one specific file, so as to
> try and keep the added cost in check.
That specific file must be checked for each file loaded from the updated
directory. So hash O(1) should be better than scanning the list.
>> I am unsure that path comparison is able to detect a problem when a user
>> reloads Org after git pull and compiling new version.
>
> If you mean `git pull; make` in Emacs's source code,
I mean reloading of updated Org from a clone of the org-mode repository
to emacs installed as a system package (or as an independent custom
built). A recent case where origin of the problem remained obscure:
Colin Baxter to emacs-orgmode. Why am I being told to use "straight.el"?
Fri, 21 Apr 2023 10:42:27 +0100.
https://list.orgmode.org/87ildpbmgs.fsf@HIDDEN
Notice that mixed version loading may happen without changing of
`load-path'. New org is loaded from the same directory.
> If you mean `git pull; make` in Org's source repository, then I must
> admit that I don't have much experience with it, but make Org's make
> file could set `load-prefer-newer`
Not enough, see beginning of the message.
> `my-require-with-shadow-check` is instead aimed at the case where the
> users try to load a mix of two different Org versions in the same Emacs
> sessions, either because of things like:
> - they're byte-compiling Org-2 in an Emacs that has Org-1 already loaded.
Does in help in the following case?
1. Base Org part is loaded on opening of some .org file.
2. Org in that directory is updated and recompiled.
3. New Org feature is loaded (autoloaded or by explicit call of e.g.
(require ob-shell))
> I my own experience `git pull; make` in Emacs's source code has
> virtually never caused me trouble with Org files,
I recall issues after introducing of `org-encode-time' and finally Ihor
replaced original macro to a less efficient function. However I am not
sure what was the real reason:
- Some issue with conditional macro definition and native compilation
- Incomplete incremental rebuilds
- Macro was not properly defined so it was disappearing from byte
compiled code.
However "undefined" complains might be similar to what I saw for
`org-assert-version'.
>> In respect to incremental builds, `org-assert-version' is a disaster.
>> Any update requires full recompiling.
>
> Indeed, I used to disable it locally (before `org--inhibit-version-check`).
By disaster I mean increased build time. `org--inhibit-version-check'
allows mixed version compilation for macros unrelated to
`org-assert-version', it is another disaster.
> Maybe a clear set of examples of the kinds of problems that
> `org-assert-version` aims to catch would be a good start.
> For me it's still not really clear.
- You are almost certainly going to ignore package.el issues in released
Emacs versions including 28.
- Besides package.el there are other package managers. I have heard of
weird issues with straight.el and org, but I have no links describing
details.
- Some users just clone org-mode repository and add that directory to
`load-path'. Directory remains the same after updates.
- Users tend to load some part of org before adding new version to
load-path: explicit require, through dependencies, unsure if org file as
startup screen may cause it as well
- User wish to update Org without restarting of Emacs. Recompiling may
be called from Emacs (e.g. package.el) or by make or other scripts.
The goals:
- prevent mixed version compiling
- prevent mixed version loading
- error message should be clear for users explaining what actions they
should perform for recovery from broken state.
I have not isolated an issue in Emacs-28 with package.el and difference
with emacs binary is running from source tree or from install tree
(.el+.elc vs. el.gz+.elc files in the directory with built-in Org and
preference of .el vs. elc in require), so I can not tell if it affects
other package managers in newer Emacs. It is the case when
`org-assert-version' prevents loading of mixed compilation result, but
user experience is terrible since simple recompilation does not help.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 4 May 2023 21:53:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 04 17:53:45 2023
Received: from localhost ([127.0.0.1]:52230 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pugtV-0002rp-CQ
for submit <at> debbugs.gnu.org; Thu, 04 May 2023 17:53:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60910)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pugtT-0002rY-NR
for 62762 <at> debbugs.gnu.org; Thu, 04 May 2023 17:53:44 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0E914442A84;
Thu, 4 May 2023 17:53:38 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C953E442A80;
Thu, 4 May 2023 17:53:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683237215;
bh=fGRYnX8OrjKs9YaYMiC2Tfue1nqLWaxKRUNoMwEJIa8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=g9BGrfhMdh3yb4EsZp5gZ9lnKWwSOtVDI2NuokS3+8Mb4RQtgwpoPHZDFPqu9jo/Y
5QFsA4Z5vuzqZu0Bh0J8W981rSZrO4K0d5SsHpX7Gl7BMhC6uuOMlP0qENj5I3M3rg
3kaomz463U4fBfGudmmNnInSnAgrKPc4QAY9qMt910T7tFQDOK9DVF0YzRkvl9PomB
PaoLAwDcj/pc9na7/1NapTP4x6pTIDNkFiFRdnUDhWpbG6B6NNKfOLigOmF/+CFXNU
0g5OW5n43GOcqBbu+zn01euXTscbNBkRuYZqKRxGgKzHRrfm0962UzP1Mf6nSpQD5H
96f6o3Oaqxvsg==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68AD2120074;
Thu, 4 May 2023 17:53:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Max Nikulin <manikulin@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> (Max Nikulin's
message of "Thu, 4 May 2023 22:31:43 +0700")
Message-ID: <jwvlei3st6i.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
<jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost>
<1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN>
Date: Thu, 04 May 2023 17:53:34 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.118 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: Ihor Radchenko <yantar92@HIDDEN>, 62762 <at> debbugs.gnu.org, bzg@HIDDEN,
dmitry@HIDDEN, Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> First of all, I think, incremental builds are broken in Emacs.
Indeed, but in practice they usually work fine. So in the absence of
a better solution, we stay with this hack and tell people to try
`make bootstrap` when there's a problem.
Also, the use of `load-prefer-newer` in lisp/Makefile eliminates most of
the brokenness we used to have in our incremental builds.
> `org-assert-version' is just the most apparent manifestation.
AFAIK `org-assert-version` tries to solve a different problem. 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).
> gcc supports generation of dependency files as a side effect of
> preprocessing for decades, see
[...]
> Perhaps a similar trick may be done in elisp by advicing e.g. `load'.
I encourage people to try that out, yes.
Having been there (many years ago), I can already warn them that an
important problem will be the presence of cyclic dependencies.
> Instead of dependency tracking Makefile in Emacs uses much more limited
> approach with the main-first target.
Hmm... no, `main-first` doesn't have much to do with dependencies (and
things like deciding when to *re*compile a file), it's concerned with
compile-time performance (typically for the first compilation, when the
`.d` dependencies wouldn't be available yet).
> That is why incremental build may easily result in mixed-version
> compilation.
Actually, now that we set `load-prefer-newer`, it is rarely a problem.
[ Of course, it can still be a problem, but only in cases such as when
a macro is changed such that the old expansion is not compatible with
code using the new definitions. This happens (e.g. when we changed
structs to use `record` instead of `vector`), but not fairly rarely. ]
> By the way, generated dependency map might help to properly reload a package
> update without restarting of Emacs.
BTW, I was reminded recently that `load-history` keeps track of
`require`s so we already have most of that info at hand.
> 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.
The idea was to check the shadowing only for one specific file, so as to
try and keep the added cost in check. Checking shadowings when
`load-path` is modified is harder (because `load-history` doesn't
remember which name was used to load a file, so it could be confused and
think a file like `lisp/progmodes/compile.el` shadows a previously
loaded `lisp/cedet/srecode/compile.el`) and could be more costly
(because it has to check for "all" files).
> I am unsure that path comparison is able to detect a problem when a user
> reloads Org after git pull and compiling new version.
[ AFAICT, there are different situations with related yet different
problems that manifest slightly differently and that may be solved
differently as well, so please be specific when you mention
problematic scenarios. ]
If you mean `git pull; make` in Emacs's source code, then AFAIK this
should almost never be a problem (thanks to `load-prefer-newer`), and if
it is, it's a general problem that's not specific to Org, and "we"
changed `org-assert-version` so as not to bother trying to solve
this case.
If you mean `git pull; make` in Org's source repository, then I must
admit that I don't have much experience with it, but make Org's make
file could set `load-prefer-newer` (or use some hack to autogenerate
`.d` dependency files :-).
`my-require-with-shadow-check` is instead aimed at the case where the
users try to load a mix of two different Org versions in the same Emacs
sessions, either because of things like:
- they're byte-compiling Org-2 in an Emacs that has Org-1 already loaded.
- they inadvertently end up loading part of Org-1 early in their init
file before they set their `load-path` to point to Org-2.
I understand Org people have had lots of problems with mixed-versions in
the past, but I personally don't know which circumstances have been more
often at the source of those problems, so maybe my suggestion addresses
a problem that's not very important, indeed.
I my own experience `git pull; make` in Emacs's source code has
virtually never caused me trouble with Org files, and it's never cause
any trouble in my checkout of Org's source code either, which is why
I'm suggesting something like `my-require-with-shadow-check`, which
targets other scenarios.
> In respect to incremental builds, `org-assert-version' is a disaster.
> Any update requires full recompiling.
Indeed, I used to disable it locally (before `org--inhibit-version-check`).
> It is a reason why I always considered it as a kludge. Unfortunately
> I do not have a better idea.
Maybe a clear set of examples of the kinds of problems that
`org-assert-version` aims to catch would be a good start.
For me it's still not really clear.
> 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.
So far I haven't seen enough of the diversity of situations are (source
of) problems to have a clear idea of what a good solution should look
like, admittedly.
`my-require-with-shadow-check` is only based on my intuition that it
might catch the most common issues where two different Org versions are
used in the same Emacs session, which seems to cover most of the
problems (except for those due to `git pull; make`, which seem to be
qualitatively of a different kind).
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 4 May 2023 15:33:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 04 11:33:17 2023 Received: from localhost ([127.0.0.1]:51850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puaxJ-00052y-Ab for submit <at> debbugs.gnu.org; Thu, 04 May 2023 11:33:17 -0400 Received: from mail-lj1-f179.google.com ([209.85.208.179]:46172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <manikulin@HIDDEN>) id 1puaxH-00052h-2C for 62762 <at> debbugs.gnu.org; Thu, 04 May 2023 11:33:16 -0400 Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2a8b1b51dbdso7743381fa.0 for <62762 <at> 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) 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) Message-ID: <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@HIDDEN> Date: Thu, 4 May 2023 22:31:43 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Content-Language: en-US To: Ihor Radchenko <yantar92@HIDDEN>, Stefan Monnier <monnier@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> From: Max Nikulin <manikulin@HIDDEN> In-Reply-To: <87bkj1g10g.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org, Alan Mackenzie <acm@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) 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.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 4 May 2023 14:10:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 04 10:10:26 2023 Received: from localhost ([127.0.0.1]:51625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puZf7-0005pj-I8 for submit <at> debbugs.gnu.org; Thu, 04 May 2023 10:10:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1puZev-0005pE-9F for 62762 <at> debbugs.gnu.org; Thu, 04 May 2023 10:10:24 -0400 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 <eliz@HIDDEN>) id 1puZeo-00068p-CE; Thu, 04 May 2023 10:10:06 -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=ZJMxFV4pjkDTaGtjJG0+jnuz6imG83nyzWrKx58y2xY=; b=ZVCSdZ2B7riM hjAXnWa/tJuUBIxj+YsFXXx904S1hy/RyEQFP1XlvcfuK5kD+ixfU5f8pd0UGCXezGgc1WzGbn3Xv L3JuNber2THiaPFsW31nUMJvN7uvNm1n/aQrBGPb7PHAZU+XUi6nT8NHVCDxTe7RXkusJSYbAi5+i I5f93PP/x2a2tSgEZgYlqUe+zTw3Hz1Jczq/ISM8hx+vpGAvBZVkbKGBaoLgDSO46vJEDJtDhhrdf 7BHUU1f5m593NqW/luON53FRWtMeISrLQRGyMlXv2i1Zc78JNCuuiePbJin6ClnoGXhv/WyalISu/ f55kdPy4eLTFJVeNcGZYSQ==; 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 <eliz@HIDDEN>) id 1puZen-0005H0-RT; Thu, 04 May 2023 10:10:06 -0400 Date: Thu, 04 May 2023 17:10:56 +0300 Message-Id: <835y98kwzz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> In-Reply-To: <ZFO6_UbeDRJJwHHx@ACM> (message from Alan Mackenzie on Thu, 4 May 2023 14:02:37 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <ZFLUB8L8azhDS4g4@ACM> <83ild8lkuc.fsf@HIDDEN> <ZFO6_UbeDRJJwHHx@ACM> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, manikulin@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Thu, 4 May 2023 14:02:37 +0000 > Cc: yantar92@HIDDEN, monnier@HIDDEN, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, manikulin@HIDDEN > From: Alan Mackenzie <acm@HIDDEN> > > > No, the situation with CC Mode solution is far from ideal. It's the > > reason that we have had the dependencies below in lisp/Makefile.in for > > the past 15 years: > > The dependencies in Lisp/Makefile are there because there are actual > dependencies between the CC Mode source files. The same is true for Org. The reason for the dependency is immaterial; the result is the same. > > Each time some of the cc-*.el files change we recompile all of them. > > The difference between this and Org is that Org has many more files, > > so spelling out their dependencies is impractical (that was the first > > possible solution I thought about when I tried to solve the Org > > issue). > > There are other subprojects in Emacs with several/many source files, > such as gnus, cedet, and calc. How do they manage to stay coherent > without special mechanisms? The "secret" is not to use macros, or use them as little as possible. Stale expanded macros from *.elc files cause breakage.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 4 May 2023 14:02:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 04 10:02:46 2023 Received: from localhost ([127.0.0.1]:51606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puZXh-0005c2-On for submit <at> debbugs.gnu.org; Thu, 04 May 2023 10:02:46 -0400 Received: from mx3.muc.de ([193.149.48.5]:30273) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1puZXf-0005bm-Si for 62762 <at> debbugs.gnu.org; Thu, 04 May 2023 10:02:44 -0400 Received: (qmail 52479 invoked by uid 3782); 4 May 2023 16:02:38 +0200 Received: from acm.muc.de (pd953a166.dip0.t-ipconnect.de [217.83.161.102]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 04 May 2023 16:02:37 +0200 Received: (qmail 17651 invoked by uid 1000); 4 May 2023 14:02:37 -0000 Date: Thu, 4 May 2023 14:02:37 +0000 To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Message-ID: <ZFO6_UbeDRJJwHHx@ACM> References: <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> <ZFLUB8L8azhDS4g4@ACM> <83ild8lkuc.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ild8lkuc.fsf@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62762 Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, monnier@HIDDEN, manikulin@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Eli. On Thu, May 04, 2023 at 08:35:55 +0300, Eli Zaretskii wrote: > > Date: Wed, 3 May 2023 21:37:11 +0000 > > Cc: Stefan Monnier <monnier@HIDDEN>, bzg@HIDDEN, dmitry@HIDDEN, > > Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org, > > Max Nikulin <manikulin@HIDDEN> > > From: Alan Mackenzie <acm@HIDDEN> > > > > It occurs to me that perhaps the CC Mode solution to the original > > problem might be useful. It was written by my predecessor at CC Mode, > > Martin Stjernholm. In ~20 years of using it, I've never had problems > > with using incorrect versions of macros, or anything like that. > No, the situation with CC Mode solution is far from ideal. It's the > reason that we have had the dependencies below in lisp/Makefile.in for > the past 15 years: The dependencies in Lisp/Makefile are there because there are actual dependencies between the CC Mode source files. I think this is orthogonal to the problems in upstream CC Mode which Martin Stjernholm solved (or, at least, worked around) with cc-bytecomp.el. They were to do with getting versions of macro files mixed up. If I've understood Ihor correctly (about which I'm far from sure), org was suffering the same problem as CC Mode was ~20 years ago, and that is the reason for the version check in org's build system. Unfortunately, org's fix for its upstream problem leaks downstream into Emacs and causes build failure, or at the very least _has_ caused such failure. My last post was suggesting that the mechanism in cc-bytecomp.el might be able to take the place of that version check, causing less aggravation for those building Emacs. > # https://debbugs.gnu.org/1004 > # CC Mode uses a compile time macro system which causes a compile time > # dependency in cc-*.elc files on the macros in other cc-*.el and the > # version string in cc-defs.el. [ .... ] > Each time some of the cc-*.el files change we recompile all of them. > The difference between this and Org is that Org has many more files, > so spelling out their dependencies is impractical (that was the first > possible solution I thought about when I tried to solve the Org > issue). There are other subprojects in Emacs with several/many source files, such as gnus, cedet, and calc. How do they manage to stay coherent without special mechanisms? -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 4 May 2023 05:35:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 04 01:35:14 2023
Received: from localhost ([127.0.0.1]:48230 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1puRcY-0004GU-DO
for submit <at> debbugs.gnu.org; Thu, 04 May 2023 01:35:14 -0400
Received: from eggs.gnu.org ([209.51.188.92]:48912)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1puRcW-0004GG-F5
for 62762 <at> debbugs.gnu.org; Thu, 04 May 2023 01:35:13 -0400
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 <eliz@HIDDEN>)
id 1puRcP-0003RH-H6; Thu, 04 May 2023 01:35:05 -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=vqpqsIZJ/W95GI0p7sec2HuAA8uM/xCwB86uX8hD8Pw=; b=GOw2igKjJJdY
ystQNTvNp0kD6bz3jXhVbRzi4ckvYEWDSzu6T7PwUMRFzCZ3cDgJOTGdKUjJdSrenpY8hjoynnyGk
Ss7ikkLFmDvce0wy0BSyxNvFqTfxxts7LXXjpII8U7kDebIIxlAS768VHSoyPOT2AtUYwI67j90tX
wx959vAkEypkTrPYVWmxkNec7Ks3uFk7DnMmb7tgi3gh19ZJI4gP4b8EgiHDTHO25Dedg/EfOKC26
j9GC/usz9tw4ADWz3FYrgKTZBek1fxe9FIlsQrrJwceCYNxH5EyUm87QsIVrDjajXsW/7yYMF8MbX
FP/zU1Yd/udkAS1vY+u0cg==;
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 <eliz@HIDDEN>)
id 1puRcO-0003Ln-WE; Thu, 04 May 2023 01:35:05 -0400
Date: Thu, 04 May 2023 08:35:55 +0300
Message-Id: <83ild8lkuc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-Reply-To: <ZFLUB8L8azhDS4g4@ACM> (message from Alan Mackenzie on Wed, 3 May
2023 21:37:11 +0000)
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
References: <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
<jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
<87bkj1g10g.fsf@localhost> <ZFLUB8L8azhDS4g4@ACM>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: yantar92@HIDDEN, 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN,
monnier@HIDDEN, manikulin@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Wed, 3 May 2023 21:37:11 +0000
> Cc: Stefan Monnier <monnier@HIDDEN>, bzg@HIDDEN, dmitry@HIDDEN,
> Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org,
> Max Nikulin <manikulin@HIDDEN>
> From: Alan Mackenzie <acm@HIDDEN>
>
> It occurs to me that perhaps the CC Mode solution to the original
> problem might be useful. It was written by my predecessor at CC Mode,
> Martin Stjernholm. In ~20 years of using it, I've never had problems
> with using incorrect versions of macros, or anything like that.
No, the situation with CC Mode solution is far from ideal. It's the
reason that we have had the dependencies below in lisp/Makefile.in for
the past 15 years:
# https://debbugs.gnu.org/1004
# CC Mode uses a compile time macro system which causes a compile time
# dependency in cc-*.elc files on the macros in other cc-*.el and the
# version string in cc-defs.el.
$(lisp)/progmodes/cc-align.elc\
$(lisp)/progmodes/cc-cmds.elc $(lisp)/progmodes/cc-compat.elc\
$(lisp)/progmodes/cc-engine.elc $(lisp)/progmodes/cc-fonts.elc\
$(lisp)/progmodes/cc-langs.elc $(lisp)/progmodes/cc-menus.elc\
$(lisp)/progmodes/cc-mode.elc $(lisp)/progmodes/cc-styles.elc\
$(lisp)/progmodes/cc-vars.elc: \
$(lisp)/progmodes/cc-bytecomp.elc $(lisp)/progmodes/cc-defs.elc
$(lisp)/progmodes/cc-align.elc $(lisp)/progmodes/cc-cmds.elc: \
$(lisp)/progmodes/cc-vars.elc $(lisp)/progmodes/cc-engine.elc
$(lisp)/progmodes/cc-compat.elc: \
$(lisp)/progmodes/cc-vars.elc $(lisp)/progmodes/cc-styles.elc \
$(lisp)/progmodes/cc-engine.elc
$(lisp)/progmodes/cc-defs.elc: $(lisp)/progmodes/cc-bytecomp.elc
$(lisp)/progmodes/cc-engine.elc: $(lisp)/progmodes/cc-langs.elc \
$(lisp)/progmodes/cc-vars.elc
$(lisp)/progmodes/cc-fonts.elc: $(lisp)/progmodes/cc-langs.elc \
$(lisp)/progmodes/cc-vars.elc $(lisp)/progmodes/cc-engine.elc
$(lisp)/progmodes/cc-langs.elc: $(lisp)/progmodes/cc-vars.elc
$(lisp)/progmodes/cc-mode.elc: $(lisp)/progmodes/cc-langs.elc \
$(lisp)/progmodes/cc-vars.elc $(lisp)/progmodes/cc-engine.elc \
$(lisp)/progmodes/cc-styles.elc $(lisp)/progmodes/cc-cmds.elc \
$(lisp)/progmodes/cc-align.elc $(lisp)/progmodes/cc-menus.elc
$(lisp)/progmodes/cc-styles.elc: $(lisp)/progmodes/cc-vars.elc \
$(lisp)/progmodes/cc-align.elc
Each time some of the cc-*.el files change we recompile all of them.
The difference between this and Org is that Org has many more files,
so spelling out their dependencies is impractical (that was the first
possible solution I thought about when I tried to solve the Org
issue).
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 3 May 2023 21:37:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 03 17:37:21 2023 Received: from localhost ([127.0.0.1]:47857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1puKA5-0006tx-4n for submit <at> debbugs.gnu.org; Wed, 03 May 2023 17:37:21 -0400 Received: from mx3.muc.de ([193.149.48.5]:56751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1puKA2-0006tg-9r for 62762 <at> debbugs.gnu.org; Wed, 03 May 2023 17:37:19 -0400 Received: (qmail 93834 invoked by uid 3782); 3 May 2023 23:37:12 +0200 Received: from acm.muc.de (pd953aedc.dip0.t-ipconnect.de [217.83.174.220]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 03 May 2023 23:37:11 +0200 Received: (qmail 8562 invoked by uid 1000); 3 May 2023 21:37:11 -0000 Date: Wed, 3 May 2023 21:37:11 +0000 To: Ihor Radchenko <yantar92@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code Message-ID: <ZFLUB8L8azhDS4g4@ACM> References: <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> <87bkj1g10g.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bkj1g10g.fsf@localhost> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org, bzg@HIDDEN, dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Max Nikulin <manikulin@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Ihor. It occurs to me that perhaps the CC Mode solution to the original problem might be useful. It was written by my predecessor at CC Mode, Martin Stjernholm. In ~20 years of using it, I've never had problems with using incorrect versions of macros, or anything like that. To quote part of the commentary from lisp/progmodes/cc-bytecomp.el: ;; This file is used to ensure that the CC Mode files are correctly ;; compiled regardless the environment (e.g. if an older CC Mode with ;; outdated macros are loaded during compilation). It also provides ;; features to defeat the compiler warnings for selected symbols. It works by pushing the correct directories onto load-path at the start of each compilation, and popping them off again at the end. Feel free to consider using this approach! -- Alan Mackenzie (Nuremberg, Germany). On Wed, May 03, 2023 at 10:30:55 +0000, Ihor Radchenko wrote: > Stefan Monnier <monnier@HIDDEN> writes: > >> This looks interesting, if we replace all the requires in Org with > >> `my-require-with-shadow-check'. > > > > If we make it signal an error, then I think we only need it for the > > requires that load "the one first file" (which you suggest could be > > `org-macs.el`). > This might work. > Max, do you see any obvious downsides in Stefan's idea about consulting > `load-history' vs. `load-path'? > >> Although, AFAIU, it does not address the problem with stale .elc files > >> kept from the previous Org version in the same folder (AFAIR, it is what > >> often happens in ELPA builds). > > > > I don't understand what you mean here: when `package.el` compiles the > > files of the Org package, that package has just been untarred into > > a fresh new directory, so there should never be any stale `.elc` files > > in there. > I am referring to https://orgmode.org/list/jwvsfkv5s7l.fsf-monnier+emacs@HIDDEN > >> And we somehow need to make sure that `my-require-with-shadow-check' is > >> available for all its users. > > > > Ah, the fun of bootstrapping :-) > I guess that the cleanest way could be putting > `require-with-shadow-check' into a new file. Then, we have no chance of > this file being loaded by old Org version. > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 3 May 2023 10:28:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 03 06:28:05 2023 Received: from localhost ([127.0.0.1]:45697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pu9iP-0004IA-9o for submit <at> debbugs.gnu.org; Wed, 03 May 2023 06:28:05 -0400 Received: from mout01.posteo.de ([185.67.36.65]:57107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pu9iF-0004HY-Fn for 62762 <at> debbugs.gnu.org; Wed, 03 May 2023 06:28:04 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EDF29240345 for <62762 <at> debbugs.gnu.org>; Wed, 3 May 2023 12:27:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1683109670; bh=sbSBN7SvYmHE0KhZ/hdxTJR1uPkcd230X1XoJcZlJhk=; h=From:To:Cc:Subject:Date:From; b=KvBGUbNTLri+6EF4cWYsbWu80hARDtQQSZbP9ScTiqZSRkVa9GxsW54+jnTdtGG1H /r3yzCTGPi7u1jqOoIuXq2wfP4/bP4dxCaH5bI4wt8vk4PgVCb5byV7oEOeKApE48y VFYFt0VvqIrJzpBVQKd+YIKFOgw+y5wA0ASWNNtSOBQMWqBCGKKDjJpqh9X/OD7f+T zXH/j2l7VxZGL8O+1bkeIphjqrmMJ0A5DM2J155xCv4KULLVNaRfRMFT9YDsCCikRI Adg7LIgmvN24PlSMel3b7PpMpCKfx3aGNB1OF+CDQoUrVEwIEROtYW3f5OrM+jmTrI /gvkJA+rizCzQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QBCnc6hckz6tn4; Wed, 3 May 2023 12:27:48 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost> <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN> Date: Wed, 03 May 2023 10:30:55 +0000 Message-ID: <87bkj1g10g.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org, Max Nikulin <manikulin@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: >> This looks interesting, if we replace all the requires in Org with >> `my-require-with-shadow-check'. > > If we make it signal an error, then I think we only need it for the > requires that load "the one first file" (which you suggest could be > `org-macs.el`). This might work. Max, do you see any obvious downsides in Stefan's idea about consulting `load-history' vs. `load-path'? >> Although, AFAIU, it does not address the problem with stale .elc files >> kept from the previous Org version in the same folder (AFAIR, it is what >> often happens in ELPA builds). > > I don't understand what you mean here: when `package.el` compiles the > files of the Org package, that package has just been untarred into > a fresh new directory, so there should never be any stale `.elc` files > in there. I am referring to https://orgmode.org/list/jwvsfkv5s7l.fsf-monnier+emacs@HIDDEN >> And we somehow need to make sure that `my-require-with-shadow-check' is >> available for all its users. > > Ah, the fun of bootstrapping :-) I guess that the cleanest way could be putting `require-with-shadow-check' into a new file. Then, we have no chance of this file being loaded by old Org version. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 2 May 2023 13:12:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 02 09:12:30 2023
Received: from localhost ([127.0.0.1]:41968 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ptpnx-0002wH-SM
for submit <at> debbugs.gnu.org; Tue, 02 May 2023 09:12:30 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27796)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1ptpnu-0002w3-TS
for 62762 <at> debbugs.gnu.org; Tue, 02 May 2023 09:12:28 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A2A74100048;
Tue, 2 May 2023 09:12:21 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 000061000BF;
Tue, 2 May 2023 09:12:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1683033140;
bh=npaVF3P4z2+x41w+AGIk0F/t0y8M25YQJ8wtONpwm9o=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=AO/cNJ5JczZs/ymmcFQAsc1HrR+DuZMEbMYGLxrfNvGvQ5FUPCQYCyF3hrSzZtgUF
wrRVbKz+HdKPhGYqYxJuaRTD+Kw7IZiS9bzJo348zDFE3MlXiSMFhS4vImNnApM6+v
96Hm8soDcRjJ/W3X4YccO+4AfsGx+rzEuLRSk1/9qt6t4YduRicerygg5tkHGlGMF5
fpsNEXBYRaWGzC/42WVsP8LQeQdhquR0zJ0fNqfwqykDHlurMeW/Z61jtzpsaFH4qn
PilGx2bbQQFMm81/AmyH6G42E2CGN3NzFOkKE+SmZu9Ya2U5TWFw5tNqc3eGaIlS/1
6uBO8ewrrMLTQ==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9786712045B;
Tue, 2 May 2023 09:12:19 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <87sfcfdldt.fsf@localhost> (Ihor Radchenko's message of "Tue, 02
May 2023 11:26:54 +0000")
Message-ID: <jwvcz3ix4os.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
<jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> <87sfcfdldt.fsf@localhost>
Date: Tue, 02 May 2023 09:12:18 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.208 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> May you provide an approximate code for that function?
>>
>> Something like (guaranteed 100% untested):
>>
>> (defun my-require-with-shadow-check (feature &optional reload)
>
> Thanks!
> This looks interesting, if we replace all the requires in Org with
> `my-require-with-shadow-check'.
If we make it signal an error, then I think we only need it for the
requires that load "the one first file" (which you suggest could be
`org-macs.el`).
> Although, AFAIU, it does not address the problem with stale .elc files
> kept from the previous Org version in the same folder (AFAIR, it is what
> often happens in ELPA builds).
I don't understand what you mean here: when `package.el` compiles the
files of the Org package, that package has just been untarred into
a fresh new directory, so there should never be any stale `.elc` files
in there.
Stale `.elc` files can happen for "in place builds", such as when doing
`git pull; make` in Emacs's source directory, but we just disabled
the mixed-version check for that case...
> And we somehow need to make sure that `my-require-with-shadow-check' is
> available for all its users.
Ah, the fun of bootstrapping :-)
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 2 May 2023 11:24:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 02 07:24:00 2023 Received: from localhost ([127.0.0.1]:41822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pto6y-0005tM-Er for submit <at> debbugs.gnu.org; Tue, 02 May 2023 07:24:00 -0400 Received: from mout02.posteo.de ([185.67.36.66]:47139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pto6t-0005su-KA for 62762 <at> debbugs.gnu.org; Tue, 02 May 2023 07:23:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1C62924030C for <62762 <at> debbugs.gnu.org>; Tue, 2 May 2023 13:23:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1683026630; bh=8nvq0rdpj9iuUZvGWoZzPniC5rAIGKv2/d6424E1Ue8=; h=From:To:Cc:Subject:Date:From; b=PKS4bjnMt39Gy451endhshMBHn9aB9HAngPQZWDz3bYbcGvhKCzcAIVumxvGBcbhn 45BPvS7D/yE3SwfkWwv6ovNZaB2+iTgbMH5FcZjwmuIMyPh1YT0DnJ/LrsCJIrivpa 3kGBvcH43CTZJYZNkBfy5ERJdaU7zbF8OC4mKTGGOloRAoBozv/4cy3eHv9615nOyM s8wcToHA+Rf+NpNpfqijgMxIxhXk6Z9HcIRcyBZcD7o4c+bpgbOy4yphFXmzzfpeFW e5oQDLDfVh4j1aZrNoNoYlz6XRrVGylCPu3iOSfPLA8sBFaEHTcsyjgmJgSSsTPLDH LhfzvkjPQCFEg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q9d4j1cnbz6tsb; Tue, 2 May 2023 13:23:48 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost> <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN> Date: Tue, 02 May 2023 11:26:54 +0000 Message-ID: <87sfcfdldt.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: >> May you provide an approximate code for that function? > > Something like (guaranteed 100% untested): > > (defun my-require-with-shadow-check (feature &optional reload) Thanks! This looks interesting, if we replace all the requires in Org with `my-require-with-shadow-check'. Although, AFAIU, it does not address the problem with stale .elc files kept from the previous Org version in the same folder (AFAIR, it is what often happens in ELPA builds). And we somehow need to make sure that `my-require-with-shadow-check' is available for all its users. Just like with `org-assert-version', older Org may not provide the function and compilation/loading can fail with "Symbol function is void". Your idea with providing built-in `require-with-shadow-check` will partially solve the latter problem. At least, on the latest Emacs. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 1 May 2023 16:49:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 01 12:49:16 2023
Received: from localhost ([127.0.0.1]:40937 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ptWiC-0007TX-4x
for submit <at> debbugs.gnu.org; Mon, 01 May 2023 12:49:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54778)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1ptWi9-0007TI-Cp
for 62762 <at> debbugs.gnu.org; Mon, 01 May 2023 12:49:14 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CF11444189E;
Mon, 1 May 2023 12:49:07 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 891F144174C;
Mon, 1 May 2023 12:49:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1682959746;
bh=AVHwR1+IDVzx3/XgPZZ4nhCqqnHIKJ69JIQkyeunOYw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=LIysqJ+YQhLQm2fi3Ju1An5tZN0KnZ/596eikHjOEBj6Z/v0EFc/8nfESxvtjy9Vi
PmN0/f8WRlU905AHZ0gsr5urrUUCoZxopsigyDgyIIBdLYpNHCcqfjv5WKomtmGALJ
/G3UbBtQy+v7OR2LAqpAn5HuW2sfnqWCnf61LqXhg+L8y8S5HTGY3qIMPFPUD8ftOD
lCKaVEH0GIrLiL7kF418SzgSpSnSnYdhNR+2fVWQEuKdDV03D+09cog5LaRrhsYsY4
4ych3FolBr5lMovY3pp637vkqthJo+0hlTfHw0RixGejkguKMTUkjg5LnBlYTDWVkL
i6z/CGoo07aPg==
Received: from alfajor (unknown [45.44.229.252])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4B10C12040D;
Mon, 1 May 2023 12:49:06 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <87cz3k8i27.fsf@localhost> (Ihor Radchenko's message of "Mon, 01
May 2023 10:25:20 +0000")
Message-ID: <jwvjzxsgg56.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
<jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> <87cz3k8i27.fsf@localhost>
Date: Mon, 01 May 2023 12:49:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.076 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> May you provide an approximate code for that function?
Something like (guaranteed 100% untested):
(defun my-require-with-shadow-check (feature &optional reload)
(if (not (featurep feature))
(require feature)
(let ((file (locate-file (symbol-name feature)
load-path (get-load-suffixes))))
(if (assoc file load-history)
;; The desired file is already loaded, we're clear!
nil
;; The feature is already provided, but from some other file
;; than expected. Presumably because `load-path` has been
;; changed since the file was loaded. This is likely a sign
;; that we're loading a mix of files from different versions.
;; That can spell trouble.
(if reload
;; Try and fix the situation by force-reloading the file
;; This may fix the problem but only if that file doesn't
;; `require` any other affected file, or if it also
;; uses `my-require-with-shadow-check` to similarly reload
;; any other affected file.
(load file nil t t)
;; We could try and find the "other/older" file in `load-history`
;; to provide better feedback to the user.
(error "Mixed versions!!"))))))
-- Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 1 May 2023 10:22:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 01 06:22:31 2023 Received: from localhost ([127.0.0.1]:39017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ptQfu-0004ar-Kh for submit <at> debbugs.gnu.org; Mon, 01 May 2023 06:22:31 -0400 Received: from mout01.posteo.de ([185.67.36.65]:37879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1ptQfp-0004aY-Ua for 62762 <at> debbugs.gnu.org; Mon, 01 May 2023 06:22:28 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6BB64240122 for <62762 <at> debbugs.gnu.org>; Mon, 1 May 2023 12:22:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682936540; bh=rbxNsQIeuFGnzXzmCtLB4KjxSe/v7cxbSG8QragtYbE=; h=From:To:Cc:Subject:Date:From; b=jpyXotyMrGxFN7osn79e41vwEa7kMnlAnfEiFaVnqz7rKp88UhXS1wmDV6oL2jFCO YvdaJCikDNb/YpYkBFWySw/c/mO0D/DerRD67WZFRpa40p6TsViaCozOqvvTk2eEbN FjUWVa2Yt3LpIyfcwN7BI2ufuzLrXsFZ1jRl6pWEGa9l7nnTHhGZ3/FEKwk1wL4oKN 7Gsc1LRLHRA9D1ImH7/hPM55g7NZL3OW6NBVG2AjZDFe5ZBlrvqH2e/iievt+yxLts JgG3m3NGFASyj3eO4XXrkegeFp8k2RnGCS1oh39MD0d8WFbbVRclKJXjifaZUIQUYj 8WNj6Zb/MBE5w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q8zmC3TlZz9rxF; Mon, 1 May 2023 12:22:19 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost> <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN> Date: Mon, 01 May 2023 10:25:20 +0000 Message-ID: <87cz3k8i27.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: > Maybe if we can identify a "first org-*.el file" (i.e. a file which > *any* use of some part of Org mode would necessarily load pretty early > on), then we can reduce this check to: Such file is org-macs.el > - check if that "first org-*.el file" is already loaded. > - if no, load it > - if yes, compare the output of `locate-file` to what is found in > `load-history`, and in case it doesn't match (because of a new > directory in `load-path`), signal an error (or maybe force a reload > instead?). > > We could even provide a new `require-with-shadow-check` function that > does just that. May you provide an approximate code for that function? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 1 May 2023 01:49:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 30 21:49:00 2023
Received: from localhost ([127.0.0.1]:38597 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ptIey-0006YV-Gd
for submit <at> debbugs.gnu.org; Sun, 30 Apr 2023 21:49:00 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17292)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1ptIew-0006YG-MR
for 62762 <at> debbugs.gnu.org; Sun, 30 Apr 2023 21:48:59 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 15F594416E1;
Sun, 30 Apr 2023 21:48:53 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D679D441560;
Sun, 30 Apr 2023 21:48:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1682905731;
bh=WEBXdQjgF99LgF/wVx07Lbm6Wv0tGtobjBme20wU0lU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=TBruRU4CoXsxb5CEz99ooLTM/YaS2XLXWoyYzIK0AYMP+F39DqBjCmCvVpuliwY5J
TSzP2Wp86MyNVHeqqdqUOO10kXcBFThg8KN0VpygJb2obsHIWNdZVg0X7RYFGxiAGq
5v7SBT7nhYDhcl9f6KoJzPdYprNNnfx8lvIzCmVWTEu38457UQNh8dzIVeLPABg7+P
MqHRx635K6T1xcwmlAesEGMliPjs/5F54fFc+3HQzQzwj1l/8i+lvVzQOTr5nAuMDo
YQ1sx+65BQcHD7YYlb79ZanFk8JH7wxlCMk0Qr+YVk3Z7hKnuZX5A8BnQhT723xpnL
EIzY9qIg6ILtQ==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 94726120312;
Sun, 30 Apr 2023 21:48:51 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <87pm7vt0mx.fsf@localhost> (Ihor Radchenko's message of "Sun, 23
Apr 2023 09:21:10 +0000")
Message-ID: <jwvo7n4zv3x.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> <87pm7vt0mx.fsf@localhost>
Date: Sun, 30 Apr 2023 21:48:50 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.038 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> BTW, have you tried to use a test along the lines of: look through
>> `load-history` to see if we loaded org-* files from a different directory
>> than the one in which `load-file-name` resides?
>
> Yup. Several problems here:
> 1. Not all the org-* files are a part of Org.
Ah right, we can't just match "org-*", indeed.
Maybe if we can identify a "first org-*.el file" (i.e. a file which
*any* use of some part of Org mode would necessarily load pretty early
on), then we can reduce this check to:
- check if that "first org-*.el file" is already loaded.
- if no, load it
- if yes, compare the output of `locate-file` to what is found in
`load-history`, and in case it doesn't match (because of a new
directory in `load-path`), signal an error (or maybe force a reload
instead?).
We could even provide a new `require-with-shadow-check` function that
does just that.
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 24 Apr 2023 12:26:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 24 08:26:42 2023 Received: from localhost ([127.0.0.1]:47763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqvHF-0001iq-SX for submit <at> debbugs.gnu.org; Mon, 24 Apr 2023 08:26:42 -0400 Received: from mout02.posteo.de ([185.67.36.66]:52405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pqvHD-0001ic-AQ for 62762 <at> debbugs.gnu.org; Mon, 24 Apr 2023 08:26:40 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C781C240254 for <62762 <at> debbugs.gnu.org>; Mon, 24 Apr 2023 14:26:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682339193; bh=4gVtQ5U1XOm3085hmS76U0TOsjwFyymAhrmcDNvxgqM=; h=From:To:Cc:Subject:Date:From; b=MHr9x5pHzPqo/qRTvGaGj9ycnY2Ig7e60XBVgV3vZt+Y+2m3IWzqSAqdyfxAC7Vqc WscpGD+jmT1Ia+ZDnKwcuxsAlH7vo+JsNCePO3lE9bfu1VnepxL5SGSlEnoetVFPCL OAiZaLK27mXh54bG/j3cY8joM5X++rFZANIEIOqju2SW1FKJ1xX8q4Byjzo99rz66E eWb7K96ujGz3NJmMVobzV791FM9ds06eVC7eaIefxhFdbLrSgneHsWp0U2c/Ds6p1f i52lGfhXMwRzE2t48Eeu+kjAYiJNJF1q4F6I+MhG8sHPiRRTN3iR2MefIRsV71AhgD pW/1EYVaNGxow== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q4krm2h9Sz6tw9; Mon, 24 Apr 2023 14:26:32 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83leihy18o.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> <87sfcrt1ta.fsf@localhost> <83leihy18o.fsf@HIDDEN> Date: Mon, 24 Apr 2023 12:29:23 +0000 Message-ID: <87fs8ptqe4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Kyle Meyer <kyle@HIDDEN>, 62762 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> Let me know when you install the change on Emacs side. > > Done. Thanks! Backported: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8eb209984 Kyle, let me know if I did anything wrong. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 24 Apr 2023 11:21:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 24 07:21:14 2023 Received: from localhost ([127.0.0.1]:47687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pquFt-0005x0-VX for submit <at> debbugs.gnu.org; Mon, 24 Apr 2023 07:21:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pquFr-0005wm-SX for 62762 <at> debbugs.gnu.org; Mon, 24 Apr 2023 07:21:12 -0400 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 <eliz@HIDDEN>) id 1pquFl-0004zu-Rg; Mon, 24 Apr 2023 07:21:05 -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=JDVzvA+mGcZekFFT8FbtUPZOgFCAwtUxhiIBt1MXd8s=; b=ecAh0QkTnC4T BbO20YLKE7r4pPBUF4cX396i4sVI7n+I2b3DJ0RKbQM1xgeg4jym0RqOiogvVsnemO8J9zV7u0ClH j+KWaVuSwEi+lYOi3Ub1JAbBKoL3GRMNzIeEx0D74k8A3pxqfzxpTGQCRZSgH5W5TQHC6I3j0d0JR 6UutlpNpzedIVFcwbQ0kwRIPFV+5XmR1fmER/MojGL2VNCo6f66NdWVS9cZGEA0eaDTdxIDayl/uZ l21CIo33pY2XOR7fDM/8x4WRsUsIHmu72LRtp16R/77KeuQ+y29REhmnePW7+BWiivSb5wLtCS25j yrEmo+CKT+p4T1kJCy7WGA==; 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 <eliz@HIDDEN>) id 1pquFj-0006Ul-JC; Mon, 24 Apr 2023 07:21:05 -0400 Date: Mon, 24 Apr 2023 14:21:27 +0300 Message-Id: <83leihy18o.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87sfcrt1ta.fsf@localhost> (message from Ihor Radchenko on Sun, 23 Apr 2023 08:55:45 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> <87sfcrt1ta.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, bzg@HIDDEN, dmitry@HIDDEN, > 62762 <at> debbugs.gnu.org > Date: Sun, 23 Apr 2023 08:55:45 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > >> I think it will be best to install the change in Emacs and then back-port > >> it to Org. Will it be ok? > > > > While you're there: could you rename that var? > > I think it should be called `org--inhibit-version-check` (no "-p" since > > it's a var and not a predicate, and more importantly no ill-defined > > notion of "built-in"). > > I have nothing against renaming. Feel free to do it together with > changing to `defvar'. > > Let me know when you install the change on Emacs side. Done.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 23 Apr 2023 09:18:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 23 05:18:28 2023 Received: from localhost ([127.0.0.1]:44622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqVrX-0006jg-NN for submit <at> debbugs.gnu.org; Sun, 23 Apr 2023 05:18:28 -0400 Received: from mout01.posteo.de ([185.67.36.65]:57383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pqVrV-0006jP-64 for 62762 <at> debbugs.gnu.org; Sun, 23 Apr 2023 05:18:26 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 50915240110 for <62762 <at> debbugs.gnu.org>; Sun, 23 Apr 2023 11:18:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682241499; bh=RYRGCpdx6S4609EvkKkmcSfROXedXXMJxMTFFFPeuXY=; h=From:To:Cc:Subject:Date:From; b=fLl/XO9tll8NcbGOdvcvyhQX1i673/r6poqVugI8bXK1MI3ZePN7e1ejhJ9mnePO5 ARiCI3xNp6sDx6xSg7kl88FkyjFc8ITuLhiCK9l3ZyKPd65ThStanYdn7HGEVPP2nT uwhWZAz5/fWa2MAueZ39JOvb2v69bYPtU/LWxmvVm7trqhd9lKD5aHyHqvDShX6tj0 zttSRTJQihC2bNaJd9g/YpDi3CpG2VnQcCmrEYKE3SYk0KXEzWWPuArYOcAqxhXFaV cupefD7Ai5ihNC6T5JwzzqNtMpXga4a86HkfYhBbEcozxqhYvsKiB9Hm8//XI9YM9S jzU6Jc2MdTyZQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q42k22Brnz6tvy; Sun, 23 Apr 2023 11:18:18 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> Date: Sun, 23 Apr 2023 09:21:10 +0000 Message-ID: <87pm7vt0mx.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: >> 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. > > In theory it's possible. Nobody has worked on it :-) > Note that it's not just macros but defsubsts as well. ... and other define-inlines. >> 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. > > Someone=E2=84=A2 *really* needs to sit down and fix the underlying proble= m in > `package.el`. The current "solution" in `package.el` *should* work (it > should reload the new `org-macs.el` on top of the old one, which > I think should avoid all the problems seen in practice for Org), so it > seems we just have a plain bug in the implementation of our "solution". > [ Which is good: it should be simple to fix, compared to trying to come > up with another solution. ] AFAIK, the current re-loading approach in package.el does help. But not all the Org users are using that new Emacs versions. And not all the Org users are using package.el. >> What we might do to work around the problem is detecting Emacs compilati= on >> and disable the check. Is there a way to detect that Emacs source is >> being compiled from Elisp? > > This sounds like adding more brittle hacks on top of brittle hacks. Sure. But I really have no better ideas, especially considering backward compatibility requirements down to Emacs 26. >> 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. > > BTW, have you tried to use a test along the lines of: look through > `load-history` to see if we loaded org-* files from a different directory > than the one in which `load-file-name` resides? Yup. Several problems here: 1. Not all the org-* files are a part of Org. 2. This will completely block the possibility for users to provide custom versions of Org libraries, when they need to. 3. We actually have `org-version' that is using this approach to indicate problems without blocking staff, but it still misses many cases. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 23 Apr 2023 08:53:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 23 04:53:07 2023 Received: from localhost ([127.0.0.1]:44617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqVT1-00064E-Aw for submit <at> debbugs.gnu.org; Sun, 23 Apr 2023 04:53:07 -0400 Received: from mout01.posteo.de ([185.67.36.65]:46607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pqVSy-00063i-DK for 62762 <at> debbugs.gnu.org; Sun, 23 Apr 2023 04:53:05 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D7FBD2400DA for <62762 <at> debbugs.gnu.org>; Sun, 23 Apr 2023 10:52:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682239978; bh=6jr3fVqqCBCSnc8EE51g+8dmYKYzLsB7c0h4EphB4qk=; h=From:To:Cc:Subject:Date:From; b=aEkb80POL688DT4lfNKJQRNcFf5IcNdQ5xW0bQhwz2/BoZ0ppV29ip3p0SZVT79Rc tAKLPm9S6o/ldncmQwE8TOplS5dnPcoAutiE2zVH1ei01laIfiakL0giQrgUcDFE2i 9764GSh+ABETEWCZif4OSSlcUSq8fmHqNq9C2TdJA3uDr5CaiSRx+er+psivug4KP9 kfmm9MnTaTSqWztUyoQlQBKxVD/UpD5ku6+UxHSh52xmBZrAF+nkc9xr9TPf9dzEtn l94dosvQ52GgZzceh5tG4OzBI4kvyo5WTg1crEj9z5k1VtRyZX0MGhfgal6YkSTLkZ 1ob8oDWs8rnsA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q428n6zWwz6ty4; Sun, 23 Apr 2023 10:52:57 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN> Date: Sun, 23 Apr 2023 08:55:45 +0000 Message-ID: <87sfcrt1ta.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: >> I think it will be best to install the change in Emacs and then back-port >> it to Org. Will it be ok? > > While you're there: could you rename that var? > I think it should be called `org--inhibit-version-check` (no "-p" since > it's a var and not a predicate, and more importantly no ill-defined > notion of "built-in"). I have nothing against renaming. Feel free to do it together with changing to `defvar'. Let me know when you install the change on Emacs side. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 14:59:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 10:59:48 2023 Received: from localhost ([127.0.0.1]:43812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqEiK-0005k6-0q for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:59:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pqEiI-0005ju-M6 for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:59:47 -0400 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 <eliz@HIDDEN>) id 1pqEiC-0003ce-1m; Sat, 22 Apr 2023 10:59:40 -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=EUPSEut+5/SzUjroONv2M9qgFyYG28YLrvz8tTQERMk=; b=KZr5tL3xzz7t xxg2i2tq9+yD9pBMw113Bl645paJRZrJPG4XT2lzpDvI+s83MDyABSS8kDrg/HGNn4Q6ien/B0Gdj Lh2kOpQXhDuANrBHDV6HHC3B5ri9kEzG3+eBwdTnN6KKBeNm30+aIvgtDcgY3L0ccPRP7xzTxKevX QE7DoZgaTNK3nzOofzkP1rOgHxsf6B/UAXOYzr5k5n+8gh4aDJfB2V3KXjdKICtHbSi1Tae3u+Nvq QB5+oO94gRjW3+0S+qZ6tHo0cd0J176Q7/IB6AoRfiIFSR/Yf0XIb0Yfyo8dZSKqpSkSReFmU3m4Q NzeI5zf7d94ZzB6xONTFjw==; 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 <eliz@HIDDEN>) id 1pqEi8-0008Q2-Bz; Sat, 22 Apr 2023 10:59:37 -0400 Date: Sat, 22 Apr 2023 17:59:55 +0300 Message-Id: <834jp80xp0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 22 Apr 2023 10:30:01 -0400) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, yantar92@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, bzg@HIDDEN, dmitry@HIDDEN, > 62762 <at> debbugs.gnu.org > Date: Sat, 22 Apr 2023 10:30:01 -0400 > > [ BTW, `rm lisp/org/*.elc` is a better solution since it avoids changing > timestamps on all those .el files. ] With current VCSs, the time stamp of versioned files is more or less random anyway. So it isn't worth it trying too hard to keep those random time stamps.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 14:33:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 10:33:06 2023
Received: from localhost ([127.0.0.1]:43793 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pqEIT-0004ut-Li
for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:33:05 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51215)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pqEIQ-0004uM-Hc
for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:33:04 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 448734412C0;
Sat, 22 Apr 2023 10:32:57 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7ADA6440A5F;
Sat, 22 Apr 2023 10:32:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1682173971;
bh=Ty6gcTkqDb/8tnU9NoK3FFY7AYgjDSd39CH2nw3HVBg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=bkE+iwojWcoSTN7THuPq5TXhZttBgzkT5BGoQhkUdleMa2JF5qV5G1NoeYckDy3ff
PPP53l8LOA3C5kKWdzZWSIjHXAyk1nABRltIP2AzHBTeXQPsaZ3S/OBEMaR8ly9WS9
Kz+NVItcNt7TJsbDSp2xKhch5xWdLDSpxoJG0qCfE6fwZWD/sgNN0iRWFJzSsyrSU6
X0X/BsKpOXjXsCBxFIqb2QFlcEBjLSAP6HCLnerzAjxzQ+CXdV8PM1gDZItN1BU0Or
cdkBz25aYHWwDxx33e5WA0u3e/B/CU4ZEfk07saZL7ZsNp2O8/lz/jHmmAdgIRp2Lp
40OTj7otspizA==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27240120315;
Sat, 22 Apr 2023 10:32:51 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <878rekum41.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
Apr 2023 12:39:42 +0000")
Message-ID: <jwvbkjg2dlh.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost>
<83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost>
<83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost>
<83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost>
<83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost>
<83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN>
<87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN>
<878rekum41.fsf@localhost>
Date: Sat, 22 Apr 2023 10:32:50 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.008 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Ihor Radchenko [2023-04-22 12:39:42] wrote:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>> I think it's the defconst thingy. E.g., with foo.el which says
>>
>> (defconst my-foo nil)
>>
>> I cannot override the value from the command line:
>>
>> emacs -Q -batch --eval "(setq my-foo t)" -l foo.el --eval "(message \"%s\" my-foo)"
>> => nil
>>
>> But if I replace defconst with defvar, it yields t, as I'd expect.
>>
>> So I think org--built-in-p should be a defvar, not defconst. Or maybe
>> you can teach me how to override a defconst? Stefan, any ideas?
>
> Well. I think I missed that `defconst', unlike `defvar', overrides the
> existing variable value. Switching to `defvar' is ok. (Or, it might be
> something like (eval-after-load 'org-macs ...), but I see no reason to
> prefer it over switching to defvar).
>
> I think it will be best to install the change in Emacs and then back-port
> it to Org. Will it be ok?
While you're there: could you rename that var?
I think it should be called `org--inhibit-version-check` (no "-p" since
it's a var and not a predicate, and more importantly no ill-defined
notion of "built-in").
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 14:30:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 10:30:16 2023
Received: from localhost ([127.0.0.1]:43788 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pqEFj-0004qj-Vu
for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:30:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6394)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1pqEFd-0004pG-K9
for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 10:30:15 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 13D10808B2;
Sat, 22 Apr 2023 10:30:04 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C42238051E;
Sat, 22 Apr 2023 10:30:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1682173802;
bh=rUkpNwVvsArFxNTkkaeDLvhgUWyBS9EVqrF9UUUuWY8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=G3i65MYThm68zNpqgsFXY5o2xTLPOP0d+PJdmHwP7X9q6v9T/KWDnFbkVTQbBqpv9
qBFVTMVFr6ZSM3awlS//y3kxwsAKhUS3a3XOlo/ykFjQZ/DxXATvgcw5atQQtITALk
w4b7FmRw6jWvPZfatxB6qeVgP7lz/qQpoxkWIeImv0UHVYCjGA4YsGy5HzhlaL8QWZ
1apwbetCGE7yvyKPVS+hN2XeqnC1vTaR0Hb81u+GNVnqafuQJ04YCz01e32n4mPmce
ixtXvjbwmLYfDI1pPS4SsZyWbNLMi92hcBZVASMSh72+FwcJp3UXUeo/qzjAa/WLN2
ZHYNW7URNukuQ==
Received: from pastel (unknown [45.72.217.176])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7FE45120315;
Sat, 22 Apr 2023 10:30:02 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <87pm8a8dx4.fsf@localhost> (Ihor Radchenko's message of "Tue, 11
Apr 2023 18:35:51 +0000")
Message-ID: <jwvh6t82ejn.fsf-monnier+emacs@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
Date: Sat, 22 Apr 2023 10:30:01 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.116 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 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.
In theory it's possible. Nobody has worked on it :-)
Note that it's not just macros but defsubsts as well.
> 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.
Someone=E2=84=A2 *really* needs to sit down and fix the underlying problem =
in
`package.el`. The current "solution" in `package.el` *should* work (it
should reload the new `org-macs.el` on top of the old one, which
I think should avoid all the problems seen in practice for Org), so it
seems we just have a plain bug in the implementation of our "solution".
[ Which is good: it should be simple to fix, compared to trying to come
up with another solution. ]
>> 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?
[ BTW, `rm lisp/org/*.elc` is a better solution since it avoids changing
timestamps on all those .el files. ]
> 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?
This sounds like adding more brittle hacks on top of brittle hacks.
>> 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.
BTW, have you tried to use a test along the lines of: look through
`load-history` to see if we loaded org-* files from a different directory
than the one in which `load-file-name` resides?
[ We may need to adjust the test to account for the `package.el`
"solution" which will result in the above test detecting a mixed
version situation even though it "should" work correctly. ]
Stefan
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 12:48:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 08:48:31 2023 Received: from localhost ([127.0.0.1]:42085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqCfH-0001Sb-CE for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 08:48:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pqCfF-0001S0-1f for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 08:48:29 -0400 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 <eliz@HIDDEN>) id 1pqCf8-0000r3-CN; Sat, 22 Apr 2023 08:48: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=yzEOwRiHKKCl9mGApry6DjMGFNk0Dl2hs7bUgpDrmow=; b=UHb46dV4/HHz xR7PQG4AexAN4IPwnAKwBM3e0Nc48nRqBwlaCMjgA8yf7YBqbd/zVASh1bocOaBxViNelcshGBhD9 gs29Hnmv0FfjBnn5Ie5D4o3Qi+HFwOQMHw5vnAhFJxF3U8XSOcDnrGVPd7J8p/YcbCwsNlqi0IdxG VVVMaYUCTbcmADNkG2V3gmWQo2FgYvhk0S9/ao/3yJYkH2mPEEzOLSiNS9DuCrmJD9KGmk0EUfkZL PgrqNrHCo+CXDIx638366fQkyqi+Btlq6WtY9OG/YCPw9gjGsnmYyICx2vFk5CcQ2PDmcNssSuAvk y3hHCg+JuvAHBQQ8DlA2kw==; 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 <eliz@HIDDEN>) id 1pqCex-0003LP-3M; Sat, 22 Apr 2023 08:48:20 -0400 Date: Sat, 22 Apr 2023 15:48:28 +0300 Message-Id: <838rek13s3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <878rekum41.fsf@localhost> (message from Ihor Radchenko on Sat, 22 Apr 2023 12:39:42 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> <878rekum41.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, bzg@HIDDEN, > dmitry@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Sat, 22 Apr 2023 12:39:42 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > So I think org--built-in-p should be a defvar, not defconst. Or maybe > > you can teach me how to override a defconst? Stefan, any ideas? > > Well. I think I missed that `defconst', unlike `defvar', overrides the > existing variable value. Switching to `defvar' is ok. (Or, it might be > something like (eval-after-load 'org-macs ...), but I see no reason to > prefer it over switching to defvar). > > I think it will be best to install the change in Emacs and then back-port > it to Org. Will it be ok? Sure, fine. Thanks.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 12:37:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 08:37:12 2023 Received: from localhost ([127.0.0.1]:42064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pqCUK-00014o-EN for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 08:37:12 -0400 Received: from mout02.posteo.de ([185.67.36.66]:34547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pqCUG-00014T-7W for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 08:37:11 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id AFEB72401E7 for <62762 <at> debbugs.gnu.org>; Sat, 22 Apr 2023 14:37:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682167022; bh=BLkHb5l52eYOvkhkegvRjyTZGh2wnh0cns2pY0oNw18=; h=From:To:Cc:Subject:Date:From; b=jizqF8m2ZLLbzEpM+uajxR6gGJtjiPn05/fyep7A+5Gu/t/MR/d1DIeECwFKdRtE7 Bj2ue8B/wemp6RA7kKkAnHDP7vrtArcEEwNM7Z1pKn8I+kzThkxMc5MxB37yqboqUj K0+f8n5IvFFKcLTSjPGt2x09Hi6Wkujqib6k/o1Q/oMKW6wv1NDmdKH9GndFQq/wbV vVh+fDvcP7WYqJb4No4sPeWcYI/2V9EN6vBsuF/yQyWYxXIc93qIdiJ1JMN+R/D34s ROglH+3dbBTjj0LSi/yV3N9I0VUElqerrQG8MTT1n1mpmXUumamdwZetqn/FIGNaNG cwaXuJ4nrJH2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q3W9n4bTWz6ty6; Sat, 22 Apr 2023 14:37:01 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83o7ng1c1p.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> <83o7ng1c1p.fsf@HIDDEN> Date: Sat, 22 Apr 2023 12:39:42 +0000 Message-ID: <878rekum41.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > I think it's the defconst thingy. E.g., with foo.el which says > > (defconst my-foo nil) > > I cannot override the value from the command line: > > emacs -Q -batch --eval "(setq my-foo t)" -l foo.el --eval "(message \"%s\" my-foo)" > => nil > > But if I replace defconst with defvar, it yields t, as I'd expect. > > So I think org--built-in-p should be a defvar, not defconst. Or maybe > you can teach me how to override a defconst? Stefan, any ideas? Well. I think I missed that `defconst', unlike `defvar', overrides the existing variable value. Switching to `defvar' is ok. (Or, it might be something like (eval-after-load 'org-macs ...), but I see no reason to prefer it over switching to defvar). I think it will be best to install the change in Emacs and then back-port it to Org. Will it be ok? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 22 Apr 2023 09:49:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 22 05:49:46 2023 Received: from localhost ([127.0.0.1]:41820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pq9sI-0001w5-HT for submit <at> debbugs.gnu.org; Sat, 22 Apr 2023 05:49:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pq9sF-0001vr-EM for 62762 <at> debbugs.gnu.org; Sat, 22 Apr 2023 05:49:45 -0400 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 <eliz@HIDDEN>) id 1pq9s9-0005y6-4p; Sat, 22 Apr 2023 05:49:37 -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=zQwQLTsZ3l1+4ae7shYeahthuDODLL4GmKg7JddhXNk=; b=JCJtza+o7N37 1UFaanlQ/PM9O4TchX6zCpVaGaMiXLaxm/bQr3ZVmuPBLexu/ICmenYXvaJqd+UsNnVXi50YJwClr VEs5S/hhGlmfJYsUlLxGCsLjdP6HRxS7mxm9K1DZEaJaNZYWY0MN0KjoYKV80bs/KPIdPW1GxIC+m lF4e0xiF7z1kSx/tCSOShW5oT3smIvP/woBthrt0lmerx816tZp706xk4+HqG7sYg4SclftdbENj/ PEBCE6Tb0iARPBZmauBaBEl1qHbFX+x2gaGpp7QmQEtxl5Ecdsl2Z2hNZuGlhK9bkWNr9niQu3Leu aAsk1GASeWB9ptiGODJ8hw==; 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 <eliz@HIDDEN>) id 1pq9s8-0003yO-6h; Sat, 22 Apr 2023 05:49:36 -0400 Date: Sat, 22 Apr 2023 12:49:54 +0300 Message-Id: <83o7ng1c1p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <87r0sdp859.fsf@localhost> (message from Ihor Radchenko on Fri, 21 Apr 2023 15:28:02 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> <87r0sdp859.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Fri, 21 Apr 2023 15:28:02 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > This doesn't seem to work as expected here? Here's what I get with > > the latest update from master: > > > > '../src/emacs.exe' -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--built-in-p t)" -f batch-byte-compile org/org-element.el > > Warning (emacs): Org version mismatch. Org loading aborted. > > This warning usually appears when a built-in Org version is loaded prior to the more recent Org version. > > > > Version mismatch is commonly encountered in the following situations: > > > > This seems to indicate that the compilation is aborted even though the > > command line sets org--built-in-p non-nil. What went wrong here? > > I see nothing wrong in the new version of the `org-assert-version' > macro. The only explanation I can come up with is that > `org-assert-version' from an older Org version somehow got mixed in. I think it's the defconst thingy. E.g., with foo.el which says (defconst my-foo nil) I cannot override the value from the command line: emacs -Q -batch --eval "(setq my-foo t)" -l foo.el --eval "(message \"%s\" my-foo)" => nil But if I replace defconst with defvar, it yields t, as I'd expect. So I think org--built-in-p should be a defvar, not defconst. Or maybe you can teach me how to override a defconst? Stefan, any ideas?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 21 Apr 2023 15:25:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 21 11:25:39 2023 Received: from localhost ([127.0.0.1]:40973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ppsdn-0003j8-A0 for submit <at> debbugs.gnu.org; Fri, 21 Apr 2023 11:25:39 -0400 Received: from mout01.posteo.de ([185.67.36.65]:50351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1ppsdl-0003iv-7U for 62762 <at> debbugs.gnu.org; Fri, 21 Apr 2023 11:25:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 36D622400C1 for <62762 <at> debbugs.gnu.org>; Fri, 21 Apr 2023 17:25:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682090731; bh=lZBGabrU4FJ+6x9odTz1wD6U7hkgjZ3SZ72VFDW7psY=; h=From:To:Cc:Subject:Date:From; b=qKzHcfnzsMfWjlrCxQuaxIAnSJtcPJFQtiTj8xCNleBnfwHTuJ4V3X2B5XneXfS7B TRUxT8cRD8LYkaKuu4AGPxI/nZ1L9MCfyL90ljeUH0SLTEIW0JnS0Z82OaCLdziute hmJt7gdZJhUCOTGYLz5avNiHWWLgSG0efeeTxzexxV4PiHCYYAII5zjpTn4hql3glq +zX+Zg3afZUqlMeT1yuLoPSmKEC6MyqpAl0pF1Cfzldkpr1rAoRjwbwQ0bCS7Y/VDt oifa06FloPG0+Hb+Ji6DhAzX4HSps7TdGGeJvoY+oc8gqhD1GN58chTjkhnLjOmuMi 57E/vK52nYJpg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q2yyf3Wcjz6tsf; Fri, 21 Apr 2023 17:25:30 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83edod4fzw.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <83edod4fzw.fsf@HIDDEN> Date: Fri, 21 Apr 2023 15:28:02 +0000 Message-ID: <87r0sdp859.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > This doesn't seem to work as expected here? Here's what I get with > the latest update from master: > > '../src/emacs.exe' -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--built-in-p t)" -f batch-byte-compile org/org-element.el > Warning (emacs): Org version mismatch. Org loading aborted. > This warning usually appears when a built-in Org version is loaded prior to the more recent Org version. > > Version mismatch is commonly encountered in the following situations: > > This seems to indicate that the compilation is aborted even though the > command line sets org--built-in-p non-nil. What went wrong here? I see nothing wrong in the new version of the `org-assert-version' macro. The only explanation I can come up with is that `org-assert-version' from an older Org version somehow got mixed in. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 21 Apr 2023 11:43:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 21 07:43:58 2023 Received: from localhost ([127.0.0.1]:39494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pppBF-0000de-QA for submit <at> debbugs.gnu.org; Fri, 21 Apr 2023 07:43:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pppBD-0000dQ-Cq for 62762 <at> debbugs.gnu.org; Fri, 21 Apr 2023 07:43:56 -0400 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 <eliz@HIDDEN>) id 1pppB6-0001m8-TV; Fri, 21 Apr 2023 07:43:48 -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=dTQQunOPLwtQGVZZyOduQhU/M18iDIRDVrsaCzulVSk=; b=FwOonCBpb7WE vgfFJ244swj57wj6RL0AsRplHpKm9bBIvBArffK4N6qrQxQy2kaQR99ABt6JKpDq9foUdUbf4AmkG NroNgFix1//twOrtaMTXQXp0gF1o/ORW6hlOaYo/dVoOz1eiOot7r05OxL5E9rrkvlnDFMgkEG1No H/t8p04Nye2yj01hSMX8kTX/SLTM3hTlRmmj83A15j5awNyVq+1VlvFsbLJ+k/fVusIUsWop4Octt TfYLslf45n12K1rvyUPLgGAX9yvnp4sLwrerGkLzWYHr055dG3AUAD2vW+kbrFfTX1xn6QzgFsJKi CESv1wbGFdbGTFgaciwhhw==; 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 <eliz@HIDDEN>) id 1pppB6-0003s6-9A; Fri, 21 Apr 2023 07:43:48 -0400 Date: Fri, 21 Apr 2023 14:44:03 +0300 Message-Id: <83edod4fzw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: yantar92@HIDDEN, bzg@HIDDEN In-Reply-To: <83pm85ctf5.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 15 Apr 2023 13:48:46 +0300) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Sat, 15 Apr 2023 13:48:46 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Ihor Radchenko <yantar92@HIDDEN> > > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > > Date: Thu, 13 Apr 2023 15:05:21 +0000 > > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > >> See the attached. > > >> On Emacs side, `org--built-in-p' will need to be set during compilation. > > > > > > LGTM, will soon incorporate this in our build system. > > > > Once you confirm that my patch + your build system update fixes the > > problem, I will push to Org bugfix and bump a minor bugfix release. > > I've now installed the change on master. > > I wonder why org--built-in-p is a defconst, though: shouldn't it be a > defvar instead? This doesn't seem to work as expected here? Here's what I get with the latest update from master: '../src/emacs.exe' -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--built-in-p t)" -f batch-byte-compile org/org-element.el Warning (emacs): Org version mismatch. Org loading aborted. This warning usually appears when a built-in Org version is loaded prior to the more recent Org version. Version mismatch is commonly encountered in the following situations: This seems to indicate that the compilation is aborted even though the command line sets org--built-in-p non-nil. What went wrong here?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 Apr 2023 12:08:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 08:08:21 2023 Received: from localhost ([127.0.0.1]:48456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pnehZ-00065a-8a for submit <at> debbugs.gnu.org; Sat, 15 Apr 2023 08:08:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pnehX-00065M-77 for 62762 <at> debbugs.gnu.org; Sat, 15 Apr 2023 08:08:19 -0400 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 <eliz@HIDDEN>) id 1pnehR-0005Kf-P4; Sat, 15 Apr 2023 08:08:13 -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=EgD0ivhPpXKPLpzUiz74z1GOiC2VEsTGTc7leqGCUNU=; b=gYa3xODI4vTR P2hIKDMWuTsxcezCa045GrEK/Qd5mGf4j3QJwZonztcMCrx9LlTBb9rY+RxDrttJnA44sGCH0srr9 CxGAgp2HnI6zuWeszSOvDYK99DO+wYMSo+H+GZydE+WO7BXD+o+5FiYdavrca9eCxv91KiHmXTdLw egQ0rfDdjSoDIlIOmevPypYmLuyKcGmFL35BrYc9uqlremT6dEm/TREYcErPCk66b/FHZELx8QxH/ tOoLa6sC5VZmHow5ADWPHf58zZmajn1Tg9pCHju0713PqdDgiZGvC7NHJWmufA8YQDH5vQ4cRw15G PcNEAQ5TGACrTsWxZkBENg==; 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 <eliz@HIDDEN>) id 1pnehQ-00029o-Rf; Sat, 15 Apr 2023 08:08:13 -0400 Date: Sat, 15 Apr 2023 15:08:13 +0300 Message-Id: <83bkjpcpqq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87fs91e4sa.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Apr 2023 11:57:57 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <87pm85e5rr.fsf@localhost> <83fs91cr0q.fsf@HIDDEN> <87fs91e4sa.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Sat, 15 Apr 2023 11:57:57 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > It's up to you, I don't mind. (But if you decide to go with defconst, > > maybe add a comment there explaining that this is the intent.) > > I updated the docstring. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix&id=07508fb09 > > The commit is now included into the new bugfix release. Thanks. The change I made in Emacs is only on master, FYI.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 Apr 2023 11:55:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 07:55:28 2023 Received: from localhost ([127.0.0.1]:48436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pneV6-0005jH-7I for submit <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:55:28 -0400 Received: from mout02.posteo.de ([185.67.36.66]:41485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pneV4-0005ix-2P for 62762 <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:55:27 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 506102401E1 for <62762 <at> debbugs.gnu.org>; Sat, 15 Apr 2023 13:55:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681559720; bh=wQyrq3r9XkIUKq3paHWHF4BDE5tnecuKI6t4vE+a0tQ=; h=From:To:Cc:Subject:Date:From; b=rM1KSlHF613NMxJi4bvWPwiroserlL6V8ZF56bct5Wjogf4YlGK1yfahnlqp5MX7Y qKaWKkKnULkCffezQs7q96N0h2w8V8fOIdr1lgBxbSasGO1Tc6qfc4M3D6kq9uWJAN 4sCYa+IkmR/z7HOggCTcMAyy7ZK9HDrx6QjXz1bUzwYmCxyodpOIUiW6dwoe/sWUwb Voiw6npo1djMk19B8V0b4PW9apQ0UlsShYzmWXC0rqJmAVoZ8bkbPStukrOQHMLs++ aPMCS71xAVPRPPcuktbVCvOrVV85SlqmX/XKhIckTHEHIK48n4O/g4bl/Y/Tb/DgN8 TAcfqDM0rs0DA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PzBZv69JVz9rxN; Sat, 15 Apr 2023 13:55:19 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83fs91cr0q.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <87pm85e5rr.fsf@localhost> <83fs91cr0q.fsf@HIDDEN> Date: Sat, 15 Apr 2023 11:57:57 +0000 Message-ID: <87fs91e4sa.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > It's up to you, I don't mind. (But if you decide to go with defconst, > maybe add a comment there explaining that this is the intent.) I updated the docstring. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix&id=07508fb09 The commit is now included into the new bugfix release. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 Apr 2023 11:40:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 07:40:46 2023 Received: from localhost ([127.0.0.1]:48408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pneGr-000572-VS for submit <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:40:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pneGp-00056p-Rp for 62762 <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:40:44 -0400 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 <eliz@HIDDEN>) id 1pneGk-00073f-Ja; Sat, 15 Apr 2023 07:40:38 -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=5l2x6pm1+tfCIRTfS0UFxzIUS8UNBNTifN+BNGHgpXo=; b=WzgoMeEBzNYs H4DMMyKp51DVNOcNi5iOQeVYkZ19V5fdMaoBGRHDYQMzjswzX9b8Nhl8rN7MYBnWH2I81VJij3RMt GjVUs7ZIT6DLtVY8rz/w/VUbdlfResgZrBggZJELtw2dEju+HnqxZwLg8wOsP8unWIeubQ3RDUD6q kpZILYck5tC1a6tdTKP8rbSJCT5RcBQbX81pNZEGexoU4WexOCqrPqvUkscfn1jShc4t9oII2utBK wKjNg64W7j/UblNo7IWh2cH4gRScCU2c8FIIBz0YEyYX2kDSif+lxo2c1oEP7eS6e07ig7rb3ZXRW 3K6lWcJpeKghIKG08FJaHw==; 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 <eliz@HIDDEN>) id 1pneGj-0004Wt-C2; Sat, 15 Apr 2023 07:40:38 -0400 Date: Sat, 15 Apr 2023 14:40:37 +0300 Message-Id: <83fs91cr0q.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87pm85e5rr.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Apr 2023 11:36:40 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> <87pm85e5rr.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Sat, 15 Apr 2023 11:36:40 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I wonder why org--built-in-p is a defconst, though: shouldn't it be a > > defvar instead? > > I wanted to make it clear that users must not set this variable. > If you think that it is excessive, I can use defvar instead. It's up to you, I don't mind. (But if you decide to go with defconst, maybe add a comment there explaining that this is the intent.)
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 Apr 2023 11:34:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 07:34:16 2023 Received: from localhost ([127.0.0.1]:48390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pneAa-0004wZ-7E for submit <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:34:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]:35243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pneAY-0004wH-52 for 62762 <at> debbugs.gnu.org; Sat, 15 Apr 2023 07:34:14 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9B40F240213 for <62762 <at> debbugs.gnu.org>; Sat, 15 Apr 2023 13:34:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681558448; bh=9LbHoOG+cJ22RHRwomz/JdoMeeR0fKiDawsWwkGGKeU=; h=From:To:Cc:Subject:Date:From; b=IceHKM/MF36HTdHTgqlJjeF9uMLJxlGePaXwRdsbl/5/7SdTWO8a154VxAi7Iwj30 SU9qhgW2QYHYMzTnUxC92pYLFNOmYXWlr87Ny8Mb723bzzt64zI2b+SYJPO+n5LWCh Gw8Mp+6nN7gYk38/qwQPThS+0SGsUG67aKag8GSBf4CvQtt9yEGVfgahLIyXpoDDqe IurSbSmbL/eucUpx4epcf8U6TYWvA6oq0EfqkD23vNY2EVz27B40VKSTy45nd7lm8E 7zrACvNbY9GTlupgZBDwcFKqIcaBcuwHuT3n18a8NpGtX0j1XzdHR0tGCGSp8415/H vyGgkcGfHmQSQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PzB6R4tP0z6tvc; Sat, 15 Apr 2023 13:34:07 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83pm85ctf5.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> <83pm85ctf5.fsf@HIDDEN> Date: Sat, 15 Apr 2023 11:36:40 +0000 Message-ID: <87pm85e5rr.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > I wonder why org--built-in-p is a defconst, though: shouldn't it be a > defvar instead? I wanted to make it clear that users must not set this variable. If you think that it is excessive, I can use defvar instead. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 15 Apr 2023 10:48:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 06:48:55 2023 Received: from localhost ([127.0.0.1]:48337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pndSh-00013D-DZ for submit <at> debbugs.gnu.org; Sat, 15 Apr 2023 06:48:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pndSf-00012y-Lt for 62762 <at> debbugs.gnu.org; Sat, 15 Apr 2023 06:48:54 -0400 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 <eliz@HIDDEN>) id 1pndSZ-0003zm-VO; Sat, 15 Apr 2023 06:48:47 -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=6UcbJwFqKbT6czdQvWKybbpPbQiblfrZuI5cBzdrk60=; b=kH/8HdJfTb/D Qh3Y+3Clh2XmefjkweEYgdzMUZFa2msZql6sO6+ynQcKC6v2hpbyt4T4ST7KsILDUN/jHD3VwkXqb VLNsYq2RxrBnmrpJorgPDaUjQOXHbdI8bWs4w9EGLvOYFD1CN8zGkCry+++eFKEoQLZJPedygshZl 2kl7mzMrmuMDOCK3vYa1fkd8dXd3naSGx7JAFp50veMOFwmOeYU82Ul/hoHjWOktbn/pQvNb55Kux /XIZhprQpRKGC9q4yF679Xa5p45SH+19HAYGGGdbHL2PdaSlgAw2Dlmmit+2OqRsYiqp6mjPjBU3P gw3MfGIq+RfJeN9ivxf2+w==; 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 <eliz@HIDDEN>) id 1pndSY-0002bQ-TU; Sat, 15 Apr 2023 06:48:47 -0400 Date: Sat, 15 Apr 2023 13:48:46 +0300 Message-Id: <83pm85ctf5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87a5zb7rgu.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 15:05:21 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> <87a5zb7rgu.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Thu, 13 Apr 2023 15:05:21 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> See the attached. > >> On Emacs side, `org--built-in-p' will need to be set during compilation. > > > > LGTM, will soon incorporate this in our build system. > > Once you confirm that my patch + your build system update fixes the > problem, I will push to Org bugfix and bump a minor bugfix release. I've now installed the change on master. I wonder why org--built-in-p is a defconst, though: shouldn't it be a defvar instead?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 Apr 2023 15:03:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 13 11:03:00 2023 Received: from localhost ([127.0.0.1]:44450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmyTU-0006kI-9r for submit <at> debbugs.gnu.org; Thu, 13 Apr 2023 11:03:00 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pmyTS-0006jz-1I for 62762 <at> debbugs.gnu.org; Thu, 13 Apr 2023 11:02:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2C119240295 for <62762 <at> debbugs.gnu.org>; Thu, 13 Apr 2023 17:02:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681398172; bh=Je+i1U1SKmNhfSvt6DRKJru+wbZAcLM0Us9723FZWBg=; h=From:To:Cc:Subject:Date:From; b=HQktkx1p9DHcMeXRzRV78qQSNTU3nJ0Pg3xCBVXvXBhUplf1OifXeh/w//kDRZE1/ OJEa+yti+24th3lUlfvNuDhNEvrt1gNWbHlqRqXInRVcn6tsmnop49swk5isnby1rg xAdmscTu31VqZ+jkj25FbsEqhGd9xWO1k4qq/Rzx6nScqQsxQaX4HjAnBA22q/HeAP U9Yl0uhYR1L9IBRLxXUwwwR+syPgOy4uFlm7KUbgIIFEuDY0haARGl54rPTmBuUq4i slyYvgtyv3ZgGePqpkwHJDucyN8w0uLXTGkfFb7G1vLBj/IbCXwbKiuePoGi3R+olN 2LIjALelCJkiQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Py2rC2CmGz6tvJ; Thu, 13 Apr 2023 17:02:51 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83o7nr4yrp.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> <83o7nr4yrp.fsf@HIDDEN> Date: Thu, 13 Apr 2023 15:05:21 +0000 Message-ID: <87a5zb7rgu.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> See the attached. >> On Emacs side, `org--built-in-p' will need to be set during compilation. > > LGTM, will soon incorporate this in our build system. Once you confirm that my patch + your build system update fixes the problem, I will push to Org bugfix and bump a minor bugfix release. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 Apr 2023 14:55:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 13 10:55:34 2023 Received: from localhost ([127.0.0.1]:44440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmyMH-00046S-SW for submit <at> debbugs.gnu.org; Thu, 13 Apr 2023 10:55:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pmyMF-00046B-6w for 62762 <at> debbugs.gnu.org; Thu, 13 Apr 2023 10:55:32 -0400 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 <eliz@HIDDEN>) id 1pmyM7-0002DL-Nd; Thu, 13 Apr 2023 10:55:25 -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=ITzlP9L5PU/d5JMFHvqOeQryl0MjKqFS2bKSb6TleAE=; b=XIVMU/cLdR05 7K5HKhbMJHoeDb6StQyMF7rc8ISfRawR1h+PqmtZ+VVYReExsO7bxhCc0sudG93oNgl2a4Pf/cHLF bp7JMc4uEP90fBck7BFEr2InUEy/Eba/0MpkhAnv8bL7vLAargIo+D4dciU8UlJXdUEM9EWEozalE YGmWxeThzN08XAC9xsitkA9kbuTvM6AC8LSPuux8/M41Plm1Zsh3xpTUc3GTGdhfxMNDXaIJEP3fL OacHV3gJyqLMi6vR63GjFJGz/cyUnbfDggB1k/GdI2sU4avmWHrApm+AXIFKd7R6btqLBVPQEwtMI 137FJFVo9wXWHXWQHMI/pQ==; 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 <eliz@HIDDEN>) id 1pmyLr-0005eD-2S; Thu, 13 Apr 2023 10:55:12 -0400 Date: Thu, 13 Apr 2023 17:55:54 +0300 Message-Id: <83o7nr4yrp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87h6tjeuei.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 14:20:05 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> <83zg7c41qq.fsf@HIDDEN> <87h6tjeuei.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Thu, 13 Apr 2023 14:20:05 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I think ELisp variable is better, since environment variables are > > inherited by sub-processes in ways that are hard to control. > > See the attached. > On Emacs side, `org--built-in-p' will need to be set during compilation. LGTM, will soon incorporate this in our build system. Thanks!
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 13 Apr 2023 14:17:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 13 10:17:51 2023
Received: from localhost ([127.0.0.1]:44377 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pmxln-0002lc-1Y
for submit <at> debbugs.gnu.org; Thu, 13 Apr 2023 10:17:51 -0400
Received: from mout02.posteo.de ([185.67.36.66]:39121)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1pmxli-0002lK-Cu
for 62762 <at> debbugs.gnu.org; Thu, 13 Apr 2023 10:17:49 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 517D32403B8
for <62762 <at> debbugs.gnu.org>; Thu, 13 Apr 2023 16:17:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1681395460; bh=OcClydrXnwseN+wotCpWXqUNZ4xUZ2nWwLOqzGZaILE=;
h=From:To:Cc:Subject:Date:From;
b=eVCXnEOCDKcRPIeXvr3o3v8y/i9STQFA82u9I7R1VLW8Vf6FGRNQvT/drrBOwXxLP
VWMwv8tXEnE3RneWUpiACPXOUEBnV/o1E8d6C2ZltKgxRdKt1rUcDNcwb6tzLvL7kN
ETcTuCrd9SArMHpDECY05LA+6Xsbcg1j/VhTkiwd7vtXtpX9UxZdF1uPdcVuLecm8h
CR4IW94eEPnTshYMwPf8+3WU5jtBIIe8oqJ8bLl9JFvZyccPl/TEo6EvJmY14RjF+8
+jqD99w/7wpKCJBZcEwdDT5vVIsAtrezFMjXocZDUGt6VIZwI7ylqYjlrPzjOj4onl
gjvTWjC/xqKFw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4Py1r33Rcpz6tsf;
Thu, 13 Apr 2023 16:17:39 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch"
after pulling a new version of the code
In-Reply-To: <83zg7c41qq.fsf@HIDDEN>
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost>
<83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost>
<83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost>
<83zg7c41qq.fsf@HIDDEN>
Date: Thu, 13 Apr 2023 14:20:05 +0000
Message-ID: <87h6tjeuei.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
> I think ELisp variable is better, since environment variables are
> inherited by sub-processes in ways that are hard to control.
See the attached.
On Emacs side, `org--built-in-p' will need to be set during compilation.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-org-assert-version-Skip-version-check-when-Org-is-a-.patch
From 89140b0d747aa127e7b06ed927c09286215e4824 Mon Sep 17 00:00:00 2001
Message-Id: <89140b0d747aa127e7b06ed927c09286215e4824.1681395507.git.yantar92@HIDDEN>
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Thu, 13 Apr 2023 16:18:15 +0200
Subject: [PATCH] org-assert-version: Skip version check when Org is a part of
Emacs
* lisp/org-macs.el (org--built-in-p): New constant indicating if Org
source is a part of Emacs source tree.
(org-assert-version): Skip check when Org is built-in.
---
lisp/org-macs.el | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index ad1d3cf14..b4a5d82c8 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -36,6 +36,9 @@ (require 'format-spec)
;;; Org version verification.
+(defconst org--built-in-p nil
+ "When non-nil, assume that Org is a part of Emacs source.
+See Emacs bug #62762.")
(defmacro org-assert-version ()
"Assert compile time and runtime version match."
;; We intentionally use a more permissive `org-release' instead of
@@ -45,7 +48,7 @@ (defmacro org-assert-version ()
;; `org-assert-version' calls would fail using strict
;; `org-git-version' check because the generated Org version strings
;; will not match.
- `(unless (equal (org-release) ,(org-release))
+ `(unless (or org--built-in-p (equal (org-release) ,(org-release)))
(warn "Org version mismatch. Org loading aborted.
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.
--
2.40.0
--=-=-=
Content-Type: text/plain
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 Apr 2023 08:36:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 13 04:36:24 2023 Received: from localhost ([127.0.0.1]:42510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmsRM-0006cc-Ah for submit <at> debbugs.gnu.org; Thu, 13 Apr 2023 04:36:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pmsRJ-0006cO-M5 for 62762 <at> debbugs.gnu.org; Thu, 13 Apr 2023 04:36:22 -0400 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 <eliz@HIDDEN>) id 1pmsRD-0004Et-2v; Thu, 13 Apr 2023 04:36:15 -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=9s8me4sESadbIbzzD3DKGUfA1xbulG0jqvuf3emjFCQ=; b=qCbDwuy/3vXp /j/Sj97PGbayGxvIdFuE6Api3A+8pPR1LZxk7ASNWl50/Jo5/l3qVQkj13TRH/7EEDsaGAyyg7nmi CLnFDVprfIWVDO1U57tM/RffSFWAP1uUDdpdxB1Znsggvb4LolebBJ9/xnNJVgpnfkPNR+Gc+J33M vgmR7VSHOEDTH2KzwNhCtSWMbNypmbkp43MH5xtqCLAlYbOEKmTnHEcqT2gIt4UM08YHgR34kzgUu 11T2b0ix948JOd5JKcxs1Xf5VwetTrDiq163faVuwCxrsM+LGxvziyaFrFbnthxrCcc4mWZvdsyNc SyweZnlO1PW4NOVRQi9aZw==; 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 <eliz@HIDDEN>) id 1pmsRB-0004ao-W1; Thu, 13 Apr 2023 04:36:14 -0400 Date: Thu, 13 Apr 2023 11:37:01 +0300 Message-Id: <83zg7c41qq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87fs94faes.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 08:34:19 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> <87fs94faes.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Thu, 13 Apr 2023 08:34:19 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> My idea is to change `org-assert-version' in such a way that the check > >> is completely bypassed when `org-version-built-in-p' is non-nil (of when > >> some environment variable is set). As I said, `org-assert-version' is > >> not aiming for built-in Org compilation. Just for Org package > >> installation. > > > > I think this will be a good change from my POV, thank you. > > So, will you prefer env variable or Elisp variable? > Environment variable is potentially more useful as it might also be used > by other code, not just by Org. I think ELisp variable is better, since environment variables are inherited by sub-processes in ways that are hard to control. Thanks.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 13 Apr 2023 08:32:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 13 04:32:01 2023 Received: from localhost ([127.0.0.1]:42503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmsN7-0006WM-JR for submit <at> debbugs.gnu.org; Thu, 13 Apr 2023 04:32:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:43707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pmsN5-0006W8-WC for 62762 <at> debbugs.gnu.org; Thu, 13 Apr 2023 04:32:00 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1BE0A240048 for <62762 <at> debbugs.gnu.org>; Thu, 13 Apr 2023 10:31:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681374714; bh=iDzqwrlblcQZVp/+7QF3gnHmPVBsg62QpYXyzneN3kg=; h=From:To:Cc:Subject:Date:From; b=Fi7NhlEeMCeJwDnQeEilpvEnIgTlL0Kx97nMX30Hk2JvUUULHGYbVCPp5FqU1lKVg RLk7qug/91R4r6SpFkMRHTciTczV2zveQP+onzcAePh7vyFGylNgeL6O2ja/6PImIu 92R0QNzFLGByeP5GkWpiDled4udF7tA+HPuNmyFV4yjUt/fqh55H/kBDxIYGlkpLKg rUvYVvxa+Ix3GDzL7sokAjcP1eHBcEIqRJTSdus+f35ErPuYVg52xrcCi9x4fQ07J+ h5H1mU2NOtkHU/naU4npC8pfK2fV8OycMZtqSrcAZcA10ojP7R95HdMk7MwE1h89Ez S8tIl+EEvb4RA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pxt9536D0z6tw2; Thu, 13 Apr 2023 10:31:53 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83zg7d78wv.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> <83zg7d78wv.fsf@HIDDEN> Date: Thu, 13 Apr 2023 08:34:19 +0000 Message-ID: <87fs94faes.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> My idea is to change `org-assert-version' in such a way that the check >> is completely bypassed when `org-version-built-in-p' is non-nil (of when >> some environment variable is set). As I said, `org-assert-version' is >> not aiming for built-in Org compilation. Just for Org package >> installation. > > I think this will be a good change from my POV, thank you. So, will you prefer env variable or Elisp variable? Environment variable is potentially more useful as it might also be used by other code, not just by Org. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 Apr 2023 09:21:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 12 05:21:00 2023 Received: from localhost ([127.0.0.1]:39048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmWex-0007dI-VV for submit <at> debbugs.gnu.org; Wed, 12 Apr 2023 05:21:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pmWev-0007d6-Ou for 62762 <at> debbugs.gnu.org; Wed, 12 Apr 2023 05:20:58 -0400 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 <eliz@HIDDEN>) id 1pmWeq-0005SD-57; Wed, 12 Apr 2023 05:20:52 -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=6gJKHpa2qo0FDKbPAECROmYnX9j2f5xfxP5DEyPlwmY=; b=btZOf4/sGbcR U7Yredxjyj+8++H3kSWE/R3rPT/yO4RAglF+SsPAsREhynn+xnAJz9mhrL9uCHEDbV29vc+YMcVj/ fD70irAT3KDnbbA3Agg8OVKHYBKhhy6L6im/k0YNH9NRMcGYSntV/4PgT+5wQEjP1u4qMiz94MKpl 8FhB0rN3vFb9XX2EoU99+0el8kmaN1rgEPgJmdUYumsPgqszjWaAfThF+kRVj6unCHZNf9kYyZxCJ 0viDl1P23Le1G7Bo2qI6WlQaLjxh+b+5REyZjU4vSyYI0QtRLoMidVhyd5l4C/ln2znvDBURCFP4f xdjmgM2JNbSyYE4I4V3vXQ==; 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 <eliz@HIDDEN>) id 1pmWep-0007D6-CZ; Wed, 12 Apr 2023 05:20:51 -0400 Date: Wed, 12 Apr 2023 12:21:36 +0300 Message-Id: <83zg7d78wv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <875ya18oaz.fsf@localhost> (message from Ihor Radchenko on Wed, 12 Apr 2023 09:03:48 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> <875ya18oaz.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Wed, 12 Apr 2023 09:03:48 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> You are not. In the worst case, we may add some flag into Org sources > >> that are inside Emacs tree. Something like `org-version-built-in-p' that > >> will be set to t only in the Emacs' version of Org. > > > > And what will that mean when org-version.el bumps its version? > > My idea is to change `org-assert-version' in such a way that the check > is completely bypassed when `org-version-built-in-p' is non-nil (of when > some environment variable is set). As I said, `org-assert-version' is > not aiming for built-in Org compilation. Just for Org package > installation. I think this will be a good change from my POV, thank you.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 12 Apr 2023 09:01:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 12 05:01:28 2023 Received: from localhost ([127.0.0.1]:39032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmWM4-000765-FD for submit <at> debbugs.gnu.org; Wed, 12 Apr 2023 05:01:28 -0400 Received: from mout01.posteo.de ([185.67.36.65]:54985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pmWM2-00075p-12 for 62762 <at> debbugs.gnu.org; Wed, 12 Apr 2023 05:01:26 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 844F12401B9 for <62762 <at> debbugs.gnu.org>; Wed, 12 Apr 2023 11:01:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681290080; bh=U0h2pIWEndEghKOsxqnpMnWuUsBbsRpWWuCYJ649AKk=; h=From:To:Cc:Subject:Date:From; b=G3Vs9EWpd9eokumQ2/ygno2K1Fry+FwyYKbUIMzE7ADuXTK3rqK5Q1r+pu/YG4iBh i2mnHN0IKIsFvkZv3u7g4TpQtwlmwD6wR2KT/JqPReB+GsT9Bw8swWwhjEArx5ZCe9 jMHB6/ZrsB9c+tg98JugEqopoRnyCdYvHytNMsXraha7qCh/wI0HysTp8290a1Caqq 8ZERpUxbwLDunqwOw5tPTpqEGchyBsJYmu0gyC5FvKba6Dk+nxy6jbiDUHkOs4Ya+q fG1nQknfkesfBK15vX4cYQIrDRNBIInDDA3JsGFksSIhuYehhTU47oERIFdB0HtM8q wU1wTHEFewlZQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PxGsW270jz6tx5; Wed, 12 Apr 2023 11:01:19 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83wn2i8bht.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN> Date: Wed, 12 Apr 2023 09:03:48 +0000 Message-ID: <875ya18oaz.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> I mean, can we detect when the compiler is invoked from "make" in Emacs >> source? > > I guess we ccoul define some environment variable in Lisp/Makefile? That should be fine. >> > I guess it means we are on our own, sigh... >> >> You are not. In the worst case, we may add some flag into Org sources >> that are inside Emacs tree. Something like `org-version-built-in-p' that >> will be set to t only in the Emacs' version of Org. > > And what will that mean when org-version.el bumps its version? My idea is to change `org-assert-version' in such a way that the check is completely bypassed when `org-version-built-in-p' is non-nil (of when some environment variable is set). As I said, `org-assert-version' is not aiming for built-in Org compilation. Just for Org package installation. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 19:36:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 15:36:57 2023
Received: from localhost ([127.0.0.1]:38290 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pmJnV-0007Pa-AW
for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 15:36:57 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53660)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1pmJnT-0007PN-8J
for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 15:36:56 -0400
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 <eliz@HIDDEN>)
id 1pmJnN-0008KW-Pu; Tue, 11 Apr 2023 15:36:49 -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=wY7oxZjoGbyTKD2KuuNXprl38dukVYc5e7kbqtAyp0k=; b=dg2OMX53Q41f
KTNCc6rTfrqydAcgGdRHey142k0PPECfI04gceuipJLg2kKS4Xirq8oE/RhQd888+la7U49IW1mbv
MjB0hkMJmjA8Jgti1FVBo/3h2/Zbw6kYesVYIUuX2NXx2y7cHKGO0pEU/lj/byXTLnBL8Jg0mrI1K
0Nhd1RyzUs2zSYU8InFqYvX1my7YwmEJQOVvyCVObS7Df2s9vqHpjzmOZ5mf6Nbx4qw4M/mHENSYt
qLKj6mR1yyznB6Cvqd33Q0u0PsXmKPKGEA+GPQVDecLDags/a7EH5wUP2GkNzjeyxkWTijqxG94T5
E+T12H4HTXoy2cMOlotIbA==;
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 <eliz@HIDDEN>)
id 1pmJnK-0005qL-JN; Tue, 11 Apr 2023 15:36:48 -0400
Date: Tue, 11 Apr 2023 22:37:29 +0300
Message-Id: <83ttxm8b2e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: yantar92@HIDDEN
In-Reply-To: <83wn2i8bht.fsf@HIDDEN> (message from Eli Zaretskii on Tue, 11
Apr 2023 22:28:14 +0300)
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
pulling a new version of the code
References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
<837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost>
<83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost>
<8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> <83wn2i8bht.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62762
Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org
> Date: Tue, 11 Apr 2023 22:28:14 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > I mean, can we detect when the compiler is invoked from "make" in Emacs
> > source?
>
> I guess we ccoul define some environment variable in Lisp/Makefile?
^^^^^
That was supposed to be "could", sorry.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 19:27:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 15:27:42 2023 Received: from localhost ([127.0.0.1]:38271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmJeY-0007B8-3O for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 15:27:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pmJeV-0007Au-Qz for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 15:27:40 -0400 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 <eliz@HIDDEN>) id 1pmJeQ-0005a3-12; Tue, 11 Apr 2023 15:27:34 -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=Py6yA9qqb5eoFfPrUGFQltnKKrllzH1xgAYBT+gUQMs=; b=FF2c3akbYmbq fENfTJrmMuMJ3kw0eR7G5JhoQ/3O8wJY6oQ4QLOfrtYON/zYF1kUp8rYYNGVwMjX6EgTJaGvJ4Nir nm5uEatenNf9LbjOMFo8bi1y+o212ACjoQLmfmwvnPAAaJOkN4Uq6XfW2g+V/yofcWa98eMYqkN0k M9GUzpoyZ73J6oUztB/v1bR1IV3HttjFcSztv05tJEWtnNkoYf6jCj2re7RzQgqTVM+sD4CnTttlp B6h/oLPZWrNrwY4WT3zJe7rF1HEAC6wEjxbSHEY+xUWkPk34jk+EJAXKfr6sZGqpvOu69T+jY1dFi edPCMTEYVaOKOevPW/wwWA==; 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 <eliz@HIDDEN>) id 1pmJeO-00013z-63; Tue, 11 Apr 2023 15:27:32 -0400 Date: Tue, 11 Apr 2023 22:28:14 +0300 Message-Id: <83wn2i8bht.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87jzyi8cu2.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 18:59:17 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> <87jzyi8cu2.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Tue, 11 Apr 2023 18:59:17 +0000 > > >> 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? > > I mean, can we detect when the compiler is invoked from "make" in Emacs > source? I guess we ccoul define some environment variable in Lisp/Makefile? > > I guess it means we are on our own, sigh... > > You are not. In the worst case, we may add some flag into Org sources > that are inside Emacs tree. Something like `org-version-built-in-p' that > will be set to t only in the Emacs' version of Org. And what will that mean when org-version.el bumps its version?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 18:57:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 14:57:00 2023 Received: from localhost ([127.0.0.1]:38237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmJAq-0006Rj-7V for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:57:00 -0400 Received: from mout01.posteo.de ([185.67.36.65]:59497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pmJAl-0006RS-FH for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:56:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9181324034D for <62762 <at> debbugs.gnu.org>; Tue, 11 Apr 2023 20:56:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681239409; bh=EqDb3/JNdUl+2rxf3iIHhTIdfsEfcHUpsB7iZn7Lur4=; h=From:To:Cc:Subject:Date:From; b=qBlCh+XEfYHSsTq9X2jibnrIaUzsRilfLlau/gqnIj3WnyKO/iM4dOLwIhv6Ni8Hh vzcABDOQB+qYO7Xghv2xJVwiEwfUZoFJXpBKQKB7saTpJ1KI6+IzbbcIOfW1wg4e4T BP9gkB1NpN3aDoDcNU2uGV6I4r5KI9H99/dAsBASJY1Jeb1IcVXgHVtyvsFJECPS/f rFXjP6KdiwTJ38DnOIVnmDcQu3EBMJSVgdFW5hPRspN2vUH8bhliQ+EbyZ1gmjJ0FD VDWqTprYkGJ34LNcfIGKddyw0JUGE5ZSPkhM1YTATbVjH4LbwqlDHXbIUZ3VlxkZhW AkH3Y5Gjevc5g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pww746rJ9z9rxD; Tue, 11 Apr 2023 20:56:48 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <8335569rs7.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> <8335569rs7.fsf@HIDDEN> Date: Tue, 11 Apr 2023 18:59:17 +0000 Message-ID: <87jzyi8cu2.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> 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. Fair point. >> 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? I mean, can we detect when the compiler is invoked from "make" in Emacs source? >> > 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... You are not. In the worst case, we may add some flag into Org sources that are inside Emacs tree. Something like `org-version-built-in-p' that will be set to t only in the Emacs' version of Org. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 18:50:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 14:50:31 2023 Received: from localhost ([127.0.0.1]:38209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmJ4Y-00068r-R8 for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:50:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pmJ4W-000684-Dx for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:50:29 -0400 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 <eliz@HIDDEN>) 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==; 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 <eliz@HIDDEN>) id 1pmJ4P-0000rw-31; Tue, 11 Apr 2023 14:50:21 -0400 Date: Tue, 11 Apr 2023 21:51:04 +0300 Message-Id: <8335569rs7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87pm8a8dx4.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 18:35:51 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> <87pm8a8dx4.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: dmitry@HIDDEN, bzg@HIDDEN, 62762 <at> debbugs.gnu.org > Date: Tue, 11 Apr 2023 18:35:51 +0000 > > Eli Zaretskii <eliz@HIDDEN> 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...
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 18:33:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 14:33:32 2023 Received: from localhost ([127.0.0.1]:38190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pmIo8-0005f7-0L for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:33:32 -0400 Received: from mout01.posteo.de ([185.67.36.65]:42023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pmIo5-0005eu-0u for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 14:33:30 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 513FA24033E for <62762 <at> 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== 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) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <83zg7ealrd.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@HIDDEN> Date: Tue, 11 Apr 2023 18:35:51 +0000 Message-ID: <87pm8a8dx4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> 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 <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 08:03:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 04:03:01 2023 Received: from localhost ([127.0.0.1]:36539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pm8xw-0001Ki-Vx for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 04:03:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pm8xv-0001KT-2D for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 04:02:59 -0400 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 <eliz@HIDDEN>) id 1pm8xp-00014Z-7m; Tue, 11 Apr 2023 04:02:53 -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=MrwNIaXpuKtWey1qbjeIKfdJPssowpmlM4B9kenuXDQ=; b=fYyryRD/Cy5B rIQfEXvKlCgXVvICOOUbKTlTTcxGIXFMu8mWKEfVwU3hkItQxeO85rSt4Rry456nnXPjN/ZGcDQSu Dw00z2y3TkfacYQ2dmWOHqk6bOX2VtuAiH1PN38kbb5EXQRXGyH+sPYxE+PnCQcgh1XciIzTIC1Lj 9ESKpmf4MCX3PIMHQ7uJumWMFiELrJVpNy4W8MVEQLpq7zffiTFTx8AfBfyb6SfGshuwKOlGNHh4n 1ZnAJMyrYFZbxLJxBbRia68G2dW4k9UywP6eqxOrn/i4jEHn0sDTNrZqg7VgBocL/WH4Qcl1NYn/N 8DemODuhIr8I9bPfyp1fsg==; 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 <eliz@HIDDEN>) id 1pm8xo-0006tY-4D; Tue, 11 Apr 2023 04:02:52 -0400 Date: Tue, 11 Apr 2023 11:03:34 +0300 Message-Id: <83zg7ealrd.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87wn2ilwed.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 07:18:18 +0000) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> <87wn2ilwed.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: bzg@HIDDEN, dmitry@HIDDEN, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Dmitry Gutov <dmitry@HIDDEN>, Bastien <bzg@HIDDEN>, > 62762 <at> debbugs.gnu.org > Date: Tue, 11 Apr 2023 07:18:18 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Or maybe Org folks (CC'ed) could suggest a better fix. I understand > > the reasons for this behavior in Org, but none of the reasons > > described in org-version.el are relevant to Emacs development, when a > > new version of Org is merged. Maybe the abort could be augmented not > > to produce such a drastic effect? > > 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. > 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. 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? 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? 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? > Maybe make bootstrap is justified then? No, it isn't. Not unless files outside of lisp/org/ will start importing org-version.el. > Of course, ideally, Emacs should provide a way to handle macro dependencies. Ideally, this would be a much nicer world, indeed. But humanity was expelled from the Garden of Eden long ago, so here we are.
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 07:16:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 03:16:12 2023 Received: from localhost ([127.0.0.1]:36506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pm8Ee-0008RS-Ip for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 03:16:12 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1pm8Ec-0008RD-1m for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 03:16:10 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 55654240326 for <62762 <at> debbugs.gnu.org>; Tue, 11 Apr 2023 09:16:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681197364; bh=5ayW2OuOORiSQgc9LC/pKcgK/aveT1OnyskK1Q2Zf28=; h=From:To:Cc:Subject:Date:From; b=eyRcOf1sWB8qdu5t7BK6SkAH5Tvs2yuCR+79/zEqW9+pTQ4p7dUGDOlhqIZS/lRcy 5dYQTDXQ+RQ9zgiADjQuXVynC1CD3FQnsuSgNwH6CCqSz2NNbXj5mTuHTwzdg6vylN DXYTyFHluClQi7i4xxMVWxqktFeRCLkbTL52ABmCPkjgtbXulwtZgBbA9EViImMZ39 JGROgt/JrlWAZoW8r6cIz2CXN0OEzlV8MB50d4KVhS7kDudff80whzWazBLv8esUJn XQABNsA47SqEqf4RxV2uJL62g5JY2QQaQcKKQ5J71p67AH1b3h0gxZceZ1d945kKQI HuV0VMfsWFXag== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PwcZW1xJhz6trm; Tue, 11 Apr 2023 09:16:02 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code In-Reply-To: <837cujaqzq.fsf@HIDDEN> References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> <837cujaqzq.fsf@HIDDEN> Date: Tue, 11 Apr 2023 07:18:18 +0000 Message-ID: <87wn2ilwed.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: Bastien <bzg@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > Or maybe Org folks (CC'ed) could suggest a better fix. I understand > the reasons for this behavior in Org, but none of the reasons > described in org-version.el are relevant to Emacs development, when a > new version of Org is merged. Maybe the abort could be augmented not > to produce such a drastic effect? The fact the Org error is triggered means that Emacs does not re-compile .el files that refer to macros that have been changed. See https://orgmode.org/list/jwvsfkv5s7l.fsf-monnier+emacs@HIDDEN 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/ Maybe make bootstrap is justified then? Of course, ideally, Emacs should provide a way to handle macro dependencies. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.Received: (at 62762) by debbugs.gnu.org; 11 Apr 2023 06:10:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 11 02:10:07 2023 Received: from localhost ([127.0.0.1]:36391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pm7Cg-0006Vk-K0 for submit <at> debbugs.gnu.org; Tue, 11 Apr 2023 02:10:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pm7Cd-0006V5-3J for 62762 <at> debbugs.gnu.org; Tue, 11 Apr 2023 02:10:04 -0400 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 <eliz@HIDDEN>) id 1pm7CU-0004pk-Nu; Tue, 11 Apr 2023 02:09:54 -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=mncJsy45RZoGo8pGztXDw6OsW/yHRIE8HGKi4bDVhgU=; b=iMBJQuo6TAVa u/uE9Ha5UZMn6R6xXKx/vRezqKuoavzvvXK5J2mejkuKwZXWaM68X8iomud7F5rrSQp9rzIx6AJpq ASPcBiWmu590Do40P4mTHWSkZEwbbBpI6nYYvp00GOCXN4Sh++NmC+3x7mWh3MsSzalP0Zh3wAgSR eUFqvfAwgXM4VlRDvFvZ4uOLgct4ZeXLElycPyzCqymI38WBSwTUlTLbYjViWxu0Eg8Ka7Ka+qPFP 0L/4ocl3CxTEPVDyjTZUASFrmge+Y7ikCTyp9Ym7tUhakvxGY8076qM7tvA43+6eyaiYrLS5UXIRC mZog/kzpqhUmohNEt2QvjA==; 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 <eliz@HIDDEN>) id 1pm7CQ-0005ex-VA; Tue, 11 Apr 2023 02:09:51 -0400 Date: Tue, 11 Apr 2023 09:10:33 +0300 Message-Id: <837cujaqzq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, Bastien <bzg@HIDDEN> In-Reply-To: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> (message from Dmitry Gutov on Tue, 11 Apr 2023 02:09:45 +0300) Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code References: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62762 Cc: 62762 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 11 Apr 2023 02:09:45 +0300 > From: Dmitry Gutov <dmitry@HIDDEN> > > Could someone fix that, so that I don't have to 'make bootstrap' every > other time after a 'git pull'? First, you don't need to "make bootstrap" in this case. It is enough to say "touch lisp/org/*.el". And second, I tried to install a solution to that on the master branch, but it is not perfect, to say the least: depending on which *.el files in lisp/org/ were updated by the same pull/merge that brought the new org-version.el (which is the source of the trouble), the solution I installed may or may not work. So a better solution is probably to "touch" all the *.el files in lisp/org/ (or just some of them, if we can identify them) when org-version.el is updated. Patches welcome, or I will get to that eventually. Or maybe Org folks (CC'ed) could suggest a better fix. I understand the reasons for this behavior in Org, but none of the reasons described in org-version.el are relevant to Emacs development, when a new version of Org is merged. Maybe the abort could be augmented not to produce such a drastic effect?
bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 10 Apr 2023 23:09:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 10 19:09:54 2023
Received: from localhost ([127.0.0.1]:36122 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pm0e1-0000di-O2
for submit <at> debbugs.gnu.org; Mon, 10 Apr 2023 19:09:54 -0400
Received: from lists.gnu.org ([209.51.188.17]:55412)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1pm0dz-0000da-Ms
for submit <at> debbugs.gnu.org; Mon, 10 Apr 2023 19:09:52 -0400
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 <dmitry@HIDDEN>) id 1pm0dz-0006Vs-HP
for bug-gnu-emacs@HIDDEN; Mon, 10 Apr 2023 19:09:51 -0400
Received: from new1-smtp.messagingengine.com ([66.111.4.221])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <dmitry@HIDDEN>) id 1pm0dx-00077z-G6
for bug-gnu-emacs@HIDDEN; Mon, 10 Apr 2023 19:09:51 -0400
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailnew.nyi.internal (Postfix) with ESMTP id EC8975822D0
for <bug-gnu-emacs@HIDDEN>; Mon, 10 Apr 2023 19:09:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute1.internal (MEProxy); Mon, 10 Apr 2023 19:09:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:content-transfer-encoding:content-type:content-type:date:date
:from:from:in-reply-to:message-id:mime-version:reply-to:sender
:subject:subject:to:to; s=fm1; t=1681168187; x=1681171787; bh=+T
/vjMdX5X0kDV5YkX1JyoK7+Q5KcTA2aOG7zfvlxIg=; b=DPSksrQrY5J7tYODnA
zHpqiMdb5nSN3g9Oajg8z0QKtLGYxKR3HwVtdNCi3re6V5GI1rHLdq7GGYJwXQ3S
39I8kPMf4HVjMOZGP3rWqJZRsJQ7OFo9fFhXfw9PeZq+v94BvwFU2G7e8sASmRb7
7myIgnFRLvBCfJNYLSSgetXzsE0otPeAj/VhsdJHARdgpBXqzq8Tv0B24bI4Z1h0
btcwvPniXzG7OFVaDEZKas8BF7q6XSViFiFjefvdi37TI+IrAsbpywnRlUwhJ2rc
RW7z4nQ3wVKRRwysVrz42QQ9tY1VaOwDQ5leg2OuTuinMiz9/2BVK2GaVfPL/Zfh
2SHw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:message-id:mime-version:reply-to:sender:subject
:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; t=1681168187; x=1681171787; bh=+T/vjMdX5X0kD
V5YkX1JyoK7+Q5KcTA2aOG7zfvlxIg=; b=NDKqnUkhf9lpuu2Er++12z/KBd1hL
Cl7+c8oo+w+WTxL37GWz4OT5P5kkkoQGPlvepYTlu/o2FL8StO5AP/PDVSlUiIgB
+wow+J3wCobYAcacbfcToWRqSt0e+NqqXR4f37yLZGABM650NGB6j6V4KQdUb0Dn
SX06E4pbS6y/XRNrPiD69FP63hQBXm5S+Vhrwx/8RJeFpK73dCYqaGS7hLEWX1CI
aDBAUuhqHL2m3swzXdeMlpmgV3DcwahgwnGQ3SDkwYFkoMQvwnO4cZd7hcO+uY3i
ur3FeeK1UL638ipQr3XFUM/ojMKXe94mgWHX/jFAOgvnKiUUesRJDfO9g==
X-ME-Sender: <xms:O5c0ZJhMuVzX1OntWCwGh8XCHSUU95Z9JMj_6R4ay8nc9H_sA30W9Q>
<xme:O5c0ZOBIzKnPvy2_KxpXsDMHe2tX9flrRlyDNoZSH2Ichq7MgGwyDeaEF6s_PNofU
gH1BzAm8fqu5FIzRZ8>
X-ME-Received: <xmr:O5c0ZJGfVDsTA4M8GvTYmif8lwygD53y1SVozJx4d264ul0pAe7MLYiPmLpElHni>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekfedgvddtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtkeertd
dtfeejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthho
vhdruggvvheqnecuggftrfgrthhtvghrnhepiefhteeugeektdduueefjeelvdeljeefje
dvlefgkeeugeejheevheehkeekleelnecuffhomhgrihhnpehmihhsmhgrthgthhdrohhr
ghdpohhrghdqsggrsggvlhdqlhhorgguqdhfihhlvgdrohhrghenucevlhhushhtvghruf
hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdr
uggvvh
X-ME-Proxy: <xmx:O5c0ZOSi82ZMOjCLpCewcaaeR4xO-vhTozqOUhBXI4dFoYsJAm4UqA>
<xmx:O5c0ZGz3iNjrKah96K0L5QChcaKpF0hGY1139VdwpqXeW7oYvLIjxw>
<xmx:O5c0ZE79EoHsaMo6unY-dNY8XRHaTjSy6cK0J7N78UUMh-ACwUOljg>
<xmx:O5c0ZLu3vNwIkd6GnMErgClRSp4fR6qNZj_0H9cFibKlGVmSiOYWOg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bug-gnu-emacs@HIDDEN>; Mon, 10 Apr 2023 19:09:46 -0400 (EDT)
Message-ID: <17b74a48-94e1-9106-cc79-d31972313910@HIDDEN>
Date: Tue, 11 Apr 2023 02:09:45 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.9.0
Content-Language: en-US
To: bug-gnu-emacs@HIDDEN
From: Dmitry Gutov <dmitry@HIDDEN>
Subject: 'make' often errors with "Org version mismatch" after pulling a new
version of the code
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=66.111.4.221; envelope-from=dmitry@HIDDEN;
helo=new1-smtp.messagingengine.com
X-Spam_score_int: -19
X-Spam_score: -2.0
X-Spam_bar: --
X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FROM_FMBLA_NEWDOM28=0.799, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.9 (-)
The log excerpt is at the end.
Could someone fix that, so that I don't have to 'make bootstrap' every
other time after a 'git pull'?
make[3]: Entering directory '/home/dgutov/vc/emacs-master/lisp'
ELC org/ox.elc
Warning (emacs): Org version mismatch. Org loading aborted.
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.
Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
version is loaded inside the file loaded by ‘org-babel-load-file’.
‘org-babel-load-file’ triggers the built-in Org version clashing
the newer Org version attempt to be loaded later.
It is recommended to move the Org loading code before the
‘org-babel-load-file’ call.
2. New Org version is loaded manually by setting ‘load-path’, but some
other package depending on Org is loaded before the ‘load-path’ is
configured.
This "other package" is triggering built-in Org version, again
causing the version mismatch.
It is recommended to set ‘load-path’ as early in the config as
possible.
3. New Org version is loaded using straight.el package manager and
other package depending on Org is loaded before straight triggers
loading of the newer Org version.
It is recommended to put
(straight-use-package 'org)
early in the config. Ideally, right after the straight.el
bootstrap. Moving ‘use-package’ :straight declaration may not be
sufficient if the corresponding ‘use-package’ statement is
deferring the loading.
In toplevel form:
org/ox.el:79:2: Error: Org version mismatch. Make sure that correct
‘load-path’ is set early in init.el
Dmitry Gutov <dmitry@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#62762; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.