Re: Permanently fix org versioning breakage during builds?

["T.V Raman" <raman@google.com>]

Also, if the problem org is running into is the result of conflicts
between org files bundled in Emacs vs those coming from an elpa
install: one way to break this knot might be:

1. Files from core Emacs should be considered the truth and stable and
   Emacs should not throw an error as long as user installs nothing
   org from elpa.

   2. If user does install from elpa, those org files are hopefully
      newer -- and that is where the version check should be thrown.
      3. If a user installing from elpa leaves around old org files,
         ie older than what is bundled in emacs, then that user
         deserves the consequences of the breakage with a hard error.

         

João Távora writes:
 > 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

--