Re: Lisp files that load cl-lib in problematical ways

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Andrea Corallo <acorallo@gnu.org>
>>>> Cc: Stephen Berman <stephen.berman@gmx.net>,  incal@dataswamp.org,
>>>>   emacs-devel@gnu.org
>>>> Date: Thu, 19 Oct 2023 09:44:51 -0400
>>>> 
>>>> Okay, I confirm that comp.el loads cl-lib, so any jit compilation
>>>> triggered loads that.
>>>
>>> This is OK, not a problem.
>>>
>>>> OTOH one thing we could do, if that's important, is to split the code
>>>> that only drives the async compilation (that actually happens in a
>>>> subprocess) so we don't load cl-lib in the Emacs the user is actually
>>>> using.  This should not be that hard (optimism mode on).
>>>
>>> I don't see the need, but I will not object if you want to make such
>>> changes.
>>
>> Okay I'll think about it, might be a positive change even leaving aside
>> the cl-lib discussion.
>
> So I did some experimentation (scratch/comp-run branch) where I splitted
> the code needed to run the (async) native compiler at runtime into a
> separete file (comp-run.el).
>
> I think it's a good change as:
>
> 1- instead of loading almost 6000 lines of compiler only code
>    (comp.el+comp-cstr.el not including dependencies) a normal user now
>    has to load only ~500 LOC.  The rest will be loaded only by the async
>    workers.
>
> 2- it is conceptually correct to divide the code needed at runtime from
>    the one necessary to actually compile.
>
> 3- at the first startup on my configuration only gv.el gets native
>    compiled!

That's a little more sorry for the mistake, in this conf the list of
native compiled files at startup is: gv.el compile.el ansi-color.el
comint.el text-property-search.el ring.el ansi-osc.el
display-line-numbers.el

  Andrea