Re: Org mode update breaking build?

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 09 May 2023 13:17:28 -0400
> 
> >> 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.

I guess you don't rebuild Emacs frequently enough.

> > 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.

The general idea is simple, indeed, but there are rocks under the
surface.  See

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#206

for the description of some of them.