Re: Org mode update breaking build?

[Sam Steingold <sds@gnu.org>]

> * Eli Zaretskii <ryvm@tah.bet> [2023-05-09 19:47:20 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Tue, 09 May 2023 12:34:29 -0400
>> 
>> > * Eli Zaretskii <ryvm@tah.bet> [2023-05-03 19:58:07 +0300]:
>> >
>> > We already fixed that, but only on master.  So you don't need to
>> > convince anyone that this needed fixing.  We are convinced.
>> 
>> I built from git master and did not get any errors.
>> However, when I visited an org-mode file, I got this:
>> 
>> --8<---------------cut here---------------start------------->8---
>> Debugger entered--Lisp error: (error "Org version mismatch.  Make sure that correct ‘load-path’ is set early in init.el")
>> --8<---------------cut here---------------end--------------->8---
>> 
>
> That's expected when there's an incompatible change.  It can also
> happen with other packages, not just with Org.  It's nothing new.

sad.

>> Basically, an apparently successful build no longer guarantees that
>> the resulting Emacs will be working.
>
> That was never guaranteed.  Not just when Org changed.

I have never seen this before, sorry.

>> It would seem that if the build process can detect this "Org version
>> mismatch", it should just `rm -f lisp/org/*.elc` and restart (remembering
>> that it tried this hack to avoid an infinite loop if it does not work).
>
> Feel free to propose how to detect this, and then restart, without
> disrupting the whole build.  We are not just compiling Org, we compile
> hundreds of Lisp files, so whatever you propose should be consistent
> with how the normal build proceeds, including its support for high
> parallelism.  If a better solution will be found, we will surely
> embrace it.

I can describe how CLISP handles this:
(https://clisp.sourceforge.io/impnotes/require.html#lib-files
and https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg00274.html)

Compilation of `foo.el` should produce 2 files:

1. `foo.elc`, as now - this is the code whose loading is functionally
   equivalent to loading `foo.el`.

2. `foo.elh` ("header") - this contains only the compile-time
   dependencies (i.e., compiled `defvar`, `defconst`, `defmacro`, and
   `defsubst` definitions and function declarations),

When the compiler sees `(require 'foo)`, it will check whether `foo.elh`
has changed since last loaded and will reload it automatically.
Note that `foo.elh` is (probably) much smaller than `foo.elc` and thus
cheaper to load.

For "pre-built" files like `subr.el` (which no other file ever requires):
when `subr.el` is recompiled, we check whether `subr.elh` has changed, and,
if it did, everything needs to be recompiled.
If it did not, no action is necessary.

Thank you for your kind an informative reply.

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://iris.org.il https://memri.org https://mideasttruth.com
To iterate is human; to recurse, divine.