From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Sun, 24 Dec 2023 08:36:52 -0800 Message-ID: <25992.24100.168620.51009@retriever.mtv.corp.google.com> 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="27402"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, raman@google.com, emacs-devel@gnu.org To: joaotavora@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 17:37:49 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 1rHRU5-0006uO-D7 for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 17:37:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHRTI-0000cm-OP; Sun, 24 Dec 2023 11:37:00 -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 1rHRTG-0000cN-MK for emacs-devel@gnu.org; Sun, 24 Dec 2023 11:36:59 -0500 Original-Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHRTE-0004Uh-Mw for emacs-devel@gnu.org; Sun, 24 Dec 2023 11:36:58 -0500 Original-Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-28bf27be6c4so1099788a91.1 for ; Sun, 24 Dec 2023 08:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703435814; x=1704040614; darn=gnu.org; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:from:to:cc:subject:date :message-id:reply-to; bh=cYEh3VRhakuhbh4ln7C3vr2Prly/sZ91lPMcjKxQRgU=; b=de13HY2bO6W+3xre/DTo4Nh/4ZEZrSSfgDb6itNZuvOtrPeQlPCN8A8nspqEFnk6VS bL4DYOr6BtReVZilIB+0udA49Gkr5JDswoWc3esWL312+yG4W33GG78d9dsd7FCPWAui kw7HxucFJJl5RqvvFGy5J5x9PqFz7751rpLjWhlDygRPq+m43d0HSAj9YfsYROJ24uAg lysN0RuV5k8GUm9wSRWddJfUHYllERPBchwkbVICPDOXBoGWC4FnK7KoNmuK85EOb57G DSF5WyS8BmUeldtttg9Bq0PzuaUq9pCNR1luDfDz8e4lwhkmf5eM6+TKMfx+HI+ta7g+ Xc0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703435814; x=1704040614; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=cYEh3VRhakuhbh4ln7C3vr2Prly/sZ91lPMcjKxQRgU=; b=vExwNXplhjTvwRaQDSAv4qDQWWvkcV7tlwjlctx3UXGowIf3OHsuElvHzW2MKFs/AG L3SU2pjaaKasOOB+aWD60T6eMdhnT2C9D4+FUE7+NGlA19SlBxAVTOeHfxDNMVLBTNSu L9ssiL8V+JXU4lrZHzXOzjf062Dd7Jc+fRXzL5ueq2CdItceYvU8c1lrKcBk4hVN6/Lz cf/waTOUDzzOd3rIUkUwhvm8U0bfJrLibbSCACbM29Hh8zzG8EfXita/8zCXsI/3gr5A E1OLl5eICrgA89+zL4CpcmRg/alCoVKK7ExmvpeWhejnqwE1JnMkGBw713WqaLSo1T92 BltA== X-Gm-Message-State: AOJu0YyvEKQcT3PyZfFii0fBQdUOF2akwi7TplljKYa5yZ7v9R5g2law zDsgUZ3qxwvTH8VLFcH9tXjMtCQvCWl8k43wEgGLWVUZTI2u X-Google-Smtp-Source: AGHT+IHpbuaLAz69/Me65pwlAFwetGfB8HJU4G7HRblFoQO1uUJMXr2dXBf0DFjxdLH10akO5Ldx7A== X-Received: by 2002:a17:902:d2c2:b0:1d4:5b0d:700a with SMTP id n2-20020a170902d2c200b001d45b0d700amr150928plc.125.1703435814062; Sun, 24 Dec 2023 08:36:54 -0800 (PST) Original-Received: from retriever.mtv.corp.google.com ([2620:15c:b5:1:fb96:5645:a684:6381]) by smtp.gmail.com with ESMTPSA id h24-20020a170902ac9800b001d36dbb22a9sm6710766plr.4.2023.12.24.08.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Dec 2023 08:36:53 -0800 (PST) In-Reply-To: X-Mailer: VM 8.1.1 under 30.0.50 (x86_64-pc-linux-gnu) Received-SPF: pass client-ip=2607:f8b0:4864:20::1032; envelope-from=raman@google.com; helo=mail-pj1-x1032.google.com X-Spam_score_int: -190 X-Spam_score: -19.1 X-Spam_bar: ------------------- X-Spam_report: (-19.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, NICE_REPLY_A=-1.463, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 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:314142 Archived-At: Also, if the problem org is running into is the result of conflicts between org files bundled in Emacs vs those coming from an elpa install: one way to break this knot might be: 1. Files from core Emacs should be considered the truth and stable and Emacs should not throw an error as long as user installs nothing org from elpa. 2. If user does install from elpa, those org files are hopefully newer -- and that is where the version check should be thrown. 3. If a user installing from elpa leaves around old org files, ie older than what is bundled in emacs, then that user deserves the consequences of the breakage with a hard error. =20 Jo=C3=A3o T=C3=A1vora writes: > 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=3F How can that be what I'm proposing if I didn't even know = about this > > > definition. Is it a form, a macro=3F > > > > > What ultimate problem is it solving=3F What condition do you nee= d to assert > > > at Emacs master build-time, failing which something else will go= wrong=3F > > > > `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 Or= g mode > > version typically installed from ELPA. This causes various unexpec= ted > > breakages. >=20 > OK, what thing does `org-assert-version` assert and what is one conc= rete > example of a breakage. Can this unexpected breakage exist if someon= e > has never ever installed Org mode from ELPA=3F >=20 > > 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= =2E >=20 > Well, this is a problem that is very commonly solved by the techniqu= e > I described. But without an example of one member of this "some mac= ros" > set and the example of one of its users in some other file, it's har= d > to justify your previous assertion that "the idea will not work". >=20 > 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: macr= os > can be hairy). >=20 > For example, the technique I described earlier cannot generally solv= e > a very similar problem with DEFSTRUCT (in our case cl-defstruct), be= cause > all the slot accessors are functions generated with cl-defstruct whi= ch have > compiler macros and removing the compiler macros would negate the di= spatching > speedup which the (only=3F) reason to choose structs over classes. >=20 > But we won't know any of this until we study the problem with some > concrete code. >=20 > > `org-assert-version' macro makes sure that no mixing like the abov= e is > > happening. > > > > > I just provided ideas on how to solve a very common build-time p= itfall 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 bru= tal ways. > > > > > Keep in mind something in the build system is causing builds to = fail with > > > cryptic messages even for people who don't use Org or rarely eve= r do. I've > > > never touched any Org related files in my life, why should it bl= ow up in my > > > face=3F 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 disc= ussing > > 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 old= er Org > > mode version). >=20 > I've seen this problem tens of times, even fairly recently, when doi= ng my > usual git pull --rebase && make routine. It's especially annoying d= uring a > git bisect. It's only solved by `make bootstrap` or `rm -rf lisp/or= g/*.elc`. >=20 > Is this problem 100% fully solved=3F >=20 > > I hope that the above clarified the situation. >=20 > No, it didn't, I'm afraid. If you know one of these macros (you all= uded > earlier to "some macros"), type its name here, please. >=20 > Jo=C3=A3o --=20