GNU bug report logs -
#62762
'make' often errors with "Org version mismatch" after pulling a new version of the code
Previous Next
Full log
Message #254 received at 62762 <at> debbugs.gnu.org (full text, mbox):
On 13/05/2023 15:46, Eli Zaretskii wrote:
>> Date: Sat, 13 May 2023 14:34:06 +0700 From: Max Nikulin
>>
>> 1. A script reads dependency files (if they exist) created during
>> previous build and removes stale .elc files.
>
> This will break if the updated files have different dependencies. You
> need to recreate the dependencies each build.
Let's consider a.el that contains (require 'd) or it autoloads some
macro from d.el. If a.el changed then a.elc is removed on this stage, so
updated a.elc will be created on the next stage. Dependency on d.elc is
known from previous build, so if d.el is changed then both a.elc and
d.elc are removed. If new (require 'd-new) is added to a.el then it is
not a problem as well. a.elc is removed due to changed a.el. d-new.elc
is either up to date or it is removed due to changes in its dependencies
or in d-new.el.
So no stale files should survive stage 1. The only issue with obsolete
dependencies is that compilation order may be not optimal.
> Also, it is not clear what is the plan for the macros. If one of the
> macros used during byte compilation changes in incompatible ways,
> trying to byte-compile using Emacs which preloaded the previous
> (outdated) definition of the macro will fail.
I hope, it is addressed above.
> So some changes need
> also to generate a new Emacs binary, not just byte-compile in the
> right order.
I expect that dependencies of the script removing stale files are
minimized. If changes in the breaks this script then it is time for
"make clean". If emacs binary depends on .elc files then some file may
be touched to let "make" know that the executable needs rebuild.
>> 2. Normal "make" pass that takes into account dependency between files
>> for ordering of compile commands. Dependency files are created or
>> updated as a side-effect of compilation.
>>
>> Likely it is reasonable to split stage 2 into steps similar to current
>> targets like main-first and mark most of files as dependent on a target
>> that (throw its dependencies) compiles files required for byte compilation.
>
> What is the plan for the various autoloads files? They depend on all
> the files, and many (all?) files depend on them.
My plan is that autoloads/loaddefs are order-only dependencies for .elc
files. However autoloads/loaddefs files depends on all files necessary
to generate them.
This bug report was last modified 1 year and 258 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.