[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
- org-assert-version considered harmful, Stefan Monnier, 2022/09/12
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/12
- Re: org-assert-version considered harmful, Timothy, 2022/09/12
- Re: org-assert-version considered harmful, Stefan Monnier, 2022/09/12
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/12
- Re: org-assert-version considered harmful,
Stefan Monnier <=
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/13
- Re: org-assert-version considered harmful, Stefan Monnier, 2022/09/13
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/13
- Re: org-assert-version considered harmful, Stefan Monnier, 2022/09/14
- Re: org-assert-version considered harmful, Tim Cross, 2022/09/14
- Re: org-assert-version considered harmful, Bastien, 2022/09/24
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/24
- Re: org-assert-version considered harmful, Timothy, 2022/09/25
- Re: org-assert-version considered harmful, Bastien, 2022/09/25
- Re: org-assert-version considered harmful, Ihor Radchenko, 2022/09/25