bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, May 04, 2023 at 08:35:55 +0300, Eli Zaretskii wrote:
> > Date: Wed, 3 May 2023 21:37:11 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, bzg@gnu.org, dmitry@gutov.dev,
> >   Eli Zaretskii <eliz@gnu.org>, 62762@debbugs.gnu.org,
> >   Max Nikulin <manikulin@gmail.com>
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > It occurs to me that perhaps the CC Mode solution to the original
> > problem might be useful.  It was written by my predecessor at CC Mode,
> > Martin Stjernholm.  In ~20 years of using it, I've never had problems
> > with using incorrect versions of macros, or anything like that.

> No, the situation with CC Mode solution is far from ideal.  It's the
> reason that we have had the dependencies below in lisp/Makefile.in for
> the past 15 years:

The dependencies in Lisp/Makefile are there because there are actual
dependencies between the CC Mode source files.  I think this is
orthogonal to the problems in upstream CC Mode which Martin Stjernholm
solved (or, at least, worked around) with cc-bytecomp.el.  They were to
do with getting versions of macro files mixed up.  If I've understood
Ihor correctly (about which I'm far from sure), org was suffering the
same problem as CC Mode was ~20 years ago, and that is the reason for
the version check in org's build system.

Unfortunately, org's fix for its upstream problem leaks downstream into
Emacs and causes build failure, or at the very least _has_ caused such
failure.  My last post was suggesting that the mechanism in
cc-bytecomp.el might be able to take the place of that version check,
causing less aggravation for those building Emacs.

>   # https://debbugs.gnu.org/1004
>   # CC Mode uses a compile time macro system which causes a compile time
>   # dependency in cc-*.elc files on the macros in other cc-*.el and the
>   # version string in cc-defs.el.

[ .... ]

> Each time some of the cc-*.el files change we recompile all of them.
> The difference between this and Org is that Org has many more files,
> so spelling out their dependencies is impractical (that was the first
> possible solution I thought about when I tried to solve the Org
> issue).

There are other subprojects in Emacs with several/many source files,
such as gnus, cedet, and calc.  How do they manage to stay coherent
without special mechanisms?

-- 
Alan Mackenzie (Nuremberg, Germany).