Re: More reliable byte compilation, take 45

[Steingold]

> * Steingold <fqf@tah.bet> [2021-10-04 12:03:34 -0400]:
>
>> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-10-04 12:51:19 +0200]:
>>
>> A defensive solution would be to recompile all libraries that require a
>> library, building a dependency tree from require/autoloads/etc, but the
>> problem is then that if you edit anything in subr.el, then you have to
>> recompile all the .el files, basically.  So it's not practical.
>
> Nevertheless, this is TRT (and your solution is far too complicated, IMO).
>
> Another solution was adopted by CLISP.
> (https://clisp.sourceforge.io/impnotes/require.html#lib-files)
>
> Briefly, compilation of `foo.el` should produce 2 files:
>
> 1. `foo.elc`, as now - this is the code whose loading is functionally
>    equivalent to loading `foo.el`
>
> 2. `foo.ell` (lib) - this contains only the compile-time dependencies
>    (i.e., compiled `defvar`, `defconst`, `defmacro`, and `defsubst`
>    definitions and function declarations)

actually, "elh" is more intuitive - this is "compiled header" file,
similar to *.h in C.

> When the byte compiler sees `(require 'foo)`, it will check that `foo.ell`
> has changed since last loaded and will reload it automatically.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1894
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://camera.org https://memri.org https://iris.org.il https://jihadwatch.org
"Sustainability" without "population growth control" is hypocrisy.