emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-assert-version considered harmful


From: Stefan Monnier
Subject: Re: org-assert-version considered harmful
Date: Tue, 13 Sep 2022 09:26:38 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> - git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
>> - make autoloads  =>  this refreshes the autoloads, but the .elc files
>>   of those .el files which didn't change still won't be recompiled.
>
> Isn't it a bug in the elpa scripts then?
> If a macro definition is changed and the .elc file using that macro is
> not changed, it still needs to be re-compiled. Otherwise, all kinds of
> unexpected side effects may appear.

Yup.  But there's no option to automatically find those dependencies in
ELisp, and (IIRC from last time I looked at it, in many packages obeying
such dependencies would end up introducing circular dependencies in
the Makefile), so we'd have to depend on the package's author to provide
a working set of file dependencies.

Note that the same problem applies to Emacs's own ELisp files.
In Emacs we have `make bootstrap` to manually get out of such
a bad compilation.

>> PPS: Maybe instead of calling `org-assert-version` everywhere, the
>>      `org-autoloads.el` (i.e. the file that sets up the `load-path` and
>>      the autoloads) could look for traces of Org files in the
>>      `load-history` and signal an error if such files are found coming
>>      from a different directory.
>
> No, unfortunately.
>
> org-autoloads, when loaded from built-in Emacs version will not help
> to catch newer Org libraries being loaded after built-in Org version is
> loaded.

Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
relegated to "late in the `load-path`" (i.e. after the directory that
holds the new-Org file) and should hence not be loaded any more (unless
someone goes through the trouble to explicitly load an old-Org files
with an absolute file name).

> Moreover, I consider loading personal forks of built-in Org libraries a
> valid use-case. Demanding all the org libraries to be loaded from the
> same directory will limit this possibility.

As long as they're loaded after new-org-autoloads.el, it would still be
fine since the test is only performed once when loading the
new-org-autoloads.el.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]