|
From: | Max Nikulin |
Subject: | Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el |
Date: | Mon, 10 Apr 2023 13:13:11 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 |
On 09/04/2023 15:29, Ihor Radchenko wrote:
Max Nikulin writes:I would consider adding to ELPA README and Org manual something like: If compiling of ELPA packages causes a lot of warnings related to `org-assert-version' then delete just installed Org package, start new Emacs session ensuring that Org is not loaded (-q?) and try to install from such clean state.What about creating org-assert-version.el file that will contain something like (if (fboundp 'org-assert-version) (org-assert-version) (warn "<workaround for compilation>")) Then, instead of (org-assert-version) call, we can put (load "org-assert-version.el") in Org libraries.
I believed that the only way to make `org-assert-version' effective is to put org version in every Org compiled .elc file, so you suggestion makes version check useless. An earlier idea was to put `org-assert-version' *definition* to a separate file keeping call in each file as one time workaround to ensure that `org-assert-version' is defined while compiling when an older Org version is loaded to Emacs < 29.
Currently I do not understand:- Why presence of .el files in the same directory (old Org version) with .elc files affects result of compilation (at least for Emacs-28)? - Why even when the `org-assert-version' macro is defined, an error is signaled on attempt to load a compiled file with unexpanded (org-assert-version) call (a file compiled with warning "the function ‘org-assert-version’ is not known")?
Unfortunately I did not bookmarked discussions containing details related to straight.el issues, so I am unsure if the problems are the same as for installing from ELPA by package.el.
[Prev in Thread] | Current Thread | [Next in Thread] |