Re: Permanently fix org versioning breakage during builds?

["João Távora" <joaotavora@gmail.com>]

On Sun, Dec 24, 2023 at 2:45 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> >> I do not think that your idea will work.
> >> What you propose is compiling `org-assert-version' once.
> >>
> >
> > Hmm? How can that be what I'm proposing if I didn't even know about this
> > definition. Is it a form, a macro?
>
> > What ultimate problem is it solving? What condition do you need to assert
> > at Emacs master build-time, failing which something else will go wrong?
>
> `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 Org mode
> version typically installed from ELPA. This causes various unexpected
> breakages.

OK, what thing does `org-assert-version` assert and what is one concrete
example of a breakage.  Can this unexpected breakage exist if someone
has never ever installed Org mode from ELPA?

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

Well, this is a problem that is very commonly solved by the technique
I described.  But without an example of one member of this "some macros"
set and the example of one of its users in some other file, it's hard
to justify your previous assertion that "the idea will not work".

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: macros
can be hairy).

For example, the technique I described earlier cannot generally solve
a very similar problem with DEFSTRUCT (in our case cl-defstruct), because
all the slot accessors are functions generated with cl-defstruct which have
compiler macros and removing the compiler macros would negate the dispatching
speedup which the (only?) reason to choose structs over classes.

But we won't know any of this until we study the problem with some
concrete code.

> `org-assert-version' macro makes sure that no mixing like the above is
> happening.
>
> > I just provided ideas on how to solve a very common build-time pitfall 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 brutal 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 ever do. I've
> > never touched any Org related files in my life, why should it blow up in my
> > face? 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 discussing
> 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 older Org
> mode version).

I've seen this problem tens of times, even fairly recently, when doing my
usual git pull --rebase && make routine.  It's especially annoying during a
git bisect.  It's only solved by `make bootstrap` or `rm -rf lisp/org/*.elc`.

Is this problem 100% fully solved?

> I hope that the above clarified the situation.

No, it didn't, I'm afraid.  If you know one of these macros (you alluded
earlier to "some macros"), type its name here, please.

João