From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Sun, 24 Dec 2023 16:32:30 +0000 Message-ID: References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> <875y0n4px0.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28019"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "T.V Raman" , emacs-devel To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 17:29:39 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 1rHRMA-00076n-7b for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 17:29:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHRLu-0005JX-Ps; Sun, 24 Dec 2023 11:29:22 -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 1rHRLu-0005JM-6E for emacs-devel@gnu.org; Sun, 24 Dec 2023 11:29:22 -0500 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHRLs-00031K-BC for emacs-devel@gnu.org; Sun, 24 Dec 2023 11:29:21 -0500 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ccba761783so6737691fa.1 for ; Sun, 24 Dec 2023 08:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703435358; x=1704040158; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ST8Li3DDooqvJQf0N8PsbGmSbKh0d5Hp2goCuM5tvMo=; b=CTe5MSEf5ls3cgtRjpTBlCvKkvnr2rV+l14AQ2AY0oPE1JwLIAA3+za3oyPv8PCVom pDRN4v9CEGTX+9n8VCEkw/ke+XHdNKG0fAVKGUxAu6gN6o+evTSuf1O4ZTi97PtqrC1r Jw4aAf11bB2Ocb1kfTpNgG8qncMcbSLEsRnMlsbBHdKr150/V2miv4E+Jy+CLvp1rJ8J Nc58XiYK/IBT/EcLeXiZLLqkXxbxqywv63JUXAeylglMU0SvfU8vldhvgOVl7TFFc8Qo bMTbEpvP8HQMBDWXn8WytU1ajTvyBCpfNAdDAHRnu/TFLWTgKEgEZtIUbY4sbtzqJKaR 6LmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703435358; x=1704040158; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ST8Li3DDooqvJQf0N8PsbGmSbKh0d5Hp2goCuM5tvMo=; b=D5/bJJolfmNzccOnnuB8iNQBLc1WHWITSSmG2OFa1ixFxl1s/WFm4LvqHNVa2mpeBK wKsWGmSqsWeiDijOJFuGEhJX2A79ubRflK48fCyx60/Cz+c07qQcdjE0D0ba5u+fUDXT iookVvGPMU7jP+cB/Rrs2trpRQmvXhnvIp3INJYajTEw8lltVMkdnBjKVdVB/o4r2WMN fEye9FFNpppt5CcBgeXtoz3j7EIvts1R9MhYPTdp8F4N0IP5/7fw2eF3Ju1t6zfp9N82 97H7SlKi2ntWdLsz9X91dqSikQpikkHNtYLoqCoJeVyxiC4bgeswYV+4rO6sihEi9Ksg 6cBw== X-Gm-Message-State: AOJu0YwXPFqzHs/4CJ6bRn6smjFM1ZGFehZDYlRcW1DpZQsjaGCPv1Jy DifGBzPOZA28kzihkBkeRlLIFYEEyc3kAM4FDak= X-Google-Smtp-Source: AGHT+IED3W1ep8BuGrbbBS37voerbl0P5H4ukeH4yklHIU1GY2pRZenVyMYHn1NssVB8eUrAG4NT3Cylho3FwRCVp1Y= X-Received: by 2002:a2e:1458:0:b0:2cc:6a3c:5dfc with SMTP id 24-20020a2e1458000000b002cc6a3c5dfcmr1674109lju.29.1703435358241; Sun, 24 Dec 2023 08:29:18 -0800 (PST) In-Reply-To: <875y0n4px0.fsf@localhost> Received-SPF: pass client-ip=2a00:1450:4864:20::22a; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x22a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:314137 Archived-At: On Sun, Dec 24, 2023 at 2:45=E2=80=AFPM Ihor Radchenko wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > >> I do not think that your idea will work. > >> What you propose is compiling `org-assert-version' once. > >> > > > > Hmm? How can that be what I'm proposing if I didn't even know about thi= s > > definition. Is it a form, a macro? > > > What ultimate problem is it solving? What condition do you need to asse= rt > > at Emacs master build-time, failing which something else will go wrong? > > `org-assert-version' is a macro. > It is solving a very common problem when some files from Org mode are > loaded from Emacs distribution and some are loaded from a newer Org mode > version typically installed from ELPA. This causes various unexpected > breakages. OK, what thing does `org-assert-version` assert and what is one concrete example of a breakage. Can this unexpected breakage exist if someone has never ever installed Org mode from ELPA? > Or, similarly, when built-in Org mode is updated, some macros are > changed, but their users are not re-compiled, leaving stale macro > expansions inside .elc files. Again, this causes various breakages. Well, this is a problem that is very commonly solved by the technique I described. But without an example of one member of this "some macros" set and the example of one of its users in some other file, it's hard to justify your previous assertion that "the idea will not work". Maybe it will, maybe it won't, or maybe it would but it would be unpractical for some reason (say, if there are hundred such macros, or if they're created by a macro-generating macro, or whatever: macros can be hairy). For example, the technique I described earlier cannot generally solve a very similar problem with DEFSTRUCT (in our case cl-defstruct), because all the slot accessors are functions generated with cl-defstruct which have compiler macros and removing the compiler macros would negate the dispatchi= ng speedup which the (only?) reason to choose structs over classes. But we won't know any of this until we study the problem with some concrete code. > `org-assert-version' macro makes sure that no mixing like the above is > happening. > > > I just provided ideas on how to solve a very common build-time pitfall = in > > Lisp. A pitfall that can be solved by requiring a recompilation of > > everything, as seems to be the current way, or in other less brutal way= s. > > > Keep in mind something in the build system is causing builds to fail wi= th > > cryptic messages even for people who don't use Org or rarely ever do. I= 've > > never touched any Org related files in my life, why should it blow up i= n my > > face? Of course happens to all package maintainers but usually there is= a > > fix. There should be one here, too. > > Nothing is blown up in your face. The version breakage we are discussing > in this thread is at runtime, when Org mode is loaded and detects that > some of .elc files for Org libraries are stale (compiled using older Org > mode version). I've seen this problem tens of times, even fairly recently, when doing my usual git pull --rebase && make routine. It's especially annoying during a git bisect. It's only solved by `make bootstrap` or `rm -rf lisp/org/*.elc= `. Is this problem 100% fully solved? > I hope that the above clarified the situation. No, it didn't, I'm afraid. If you know one of these macros (you alluded earlier to "some macros"), type its name here, please. Jo=C3=A3o