>> - 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