From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Sun, 24 Dec 2023 20:47:47 +0200 Message-ID: <83mstzbfos.fsf@gnu.org> References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> <875y0n4px0.fsf@localhost> <87v88n3515.fsf@localhost> <87mstz34ec.fsf@localhost> <87jzp3344t.fsf@localhost> <87cyuv320s.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, raman@google.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 19:48:06 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rHTWA-0003v5-FI for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 19:48:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHTVy-00043Y-3o; Sun, 24 Dec 2023 13:47:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHTVw-00040q-E5 for emacs-devel@gnu.org; Sun, 24 Dec 2023 13:47:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHTVw-0005x9-46; Sun, 24 Dec 2023 13:47:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=l8QGboutaGO38wM8OvV4TaZXeB1YWL0w+AYWsWpbYfU=; b=BLX6R0KVkP8h7C8gTOXB 6/mraT/MMIbjtohObsZ6BalcDSSg1YIKeymMXoXg+32zOuko97FSZ1s9x4XDK+Kr9WmVQBXgPHr1H 1Qhpfsrsu7vabPgoav45EzKCZ2NEVraiI7hVmwo9r5SpHDRH0QW6SDnT/Vy7nX4DUmyagqvfXeYyr McsQt2pUqU9jtCrz4yqjhBV4EIa9J7wA4HcJDV91jQWEiIBnPsFaFIScV5F+C5U0wEKMTw1eERG5l /Zc2664JN1yu3ou8ExtI7xSD44d0e/eBAfa/bC/6jEXSLL1+KhcP4WxpLyD2Q05xdOndhLygAWjBd yDrEMIve7lbwXw==; In-Reply-To: <87cyuv320s.fsf@localhost> (message from Ihor Radchenko on Sun, 24 Dec 2023 18:10:11 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314179 Archived-At: > From: Ihor Radchenko > Cc: "T.V Raman" , emacs-devel > Date: Sun, 24 Dec 2023 18:10:11 +0000 > > João Távora writes: > > > The problem could for example be solved by variable-watching load-path > > carefully. > > org-assert-version is the best we came up with. > If you know a concrete idea how to solve it differently, feel free to > share it. Why not just let things break when incompatible changes in Org macros are installed? We do that for any other Lisp file in the repository that defines macros used by other files. Why cannot Org do the same when it is compiled as part of the Emacs build? IOW, why not simply disable the version test as part of the Emacs build, and leave the breakage for those cases where (a) changes in macros are really incompatible and (b) they affect Org code that is being run as part of the build?