Re: Org mode update breaking build?

[Eli Zaretskii <eliz@gnu.org>]

> 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")
>   error("Org version mismatch.  Make sure that correct `load-path' is set early in init.el")
>   byte-code(...)
>   require(org-keys)
>   byte-code(...)
>   org-mode()
>   set-auto-mode-0(org-mode nil)
>   set-auto-mode()
>   normal-mode(t)
>   after-find-file(nil t)
>   find-file-noselect-1(#<buffer xxx.txt> "~/xxx.txt" nil nil "~/xxx.txt" (1180547 66307))
>   find-file-noselect("~/xxx.txt" nil nil t)
>   find-file("~/xxx.txt" t)
>   funcall-interactively(find-file "~/xxx.txt" t)
>   command-execute(find-file)
> --8<---------------cut here---------------end--------------->8---
> 
> (along with the usual long but worthless instructions)

That's expected when there's an incompatible change.  It can also
happen with other packages, not just with Org.  It's nothing new.

> Basically, an apparently successful build no longer guarantees that the
> resulting Emacs will be working.

That was never guaranteed.  Not just when Org changed.

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