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.
>
> Okay in scratch/comp-run we have a branch that does not require to load
> comp.el for jit compilations and for installing already existing
> trampolines (compiling a new trampolines indeed require to load the
> compiler).
>
> It achieves that adding comp-run.el for runtime dependencies.
>
> Still the compiler is loaded for C-h f, to solve that I think we'd need
> to add a third file (ex comp-common.el), not sure it's worth ATM.

I think what is now in scratch/comp-run does what we want.  If there are
no objections I'll push it to master after some polishing in the
following days.

Bests

  Andrea