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

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: Emanuel Berg <incal@dataswamp.org>,  emacs-devel@gnu.org
>>> Date: Thu, 19 Oct 2023 09:34:39 +0200
>>> 
>>> On Thu, 19 Oct 2023 07:54:12 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> >   (featurep 'cl-lib) => nil
>>> >
>>> > both in GUI and TTY (i.e. -nw) sessions.
>>> 
>>> I also get this in a freshly updated build from master both with -Q and
>>> with -Q -nw.  In a freshly updated build from emacs-29 I also get it
>>> with -Q -nw, but with just -Q (i.e. the GUI) it returns `t', and
>>> evaluating `features' returns (time-date subr-x cl-loaddefs cl-lib
>>> rmc...).  And in a GUI build from master from October 8, (featurep
>>> 'cl-lib) returns `t' and features returns (time-date subr-x cl-loaddefs
>>> cl-lib rmc...).
>>
>> Please try figuring out what loads cl-lib in your case, as I cannot
>> reproduce this with the latest emacs-29 branch.
>
> Maybe the native compiler as it was triggered for some native
> compilation?

Okay, I confirm that comp.el loads cl-lib, so any jit compilation
triggered loads that.

emacs -Q on my system at the first run (not in the followings) loads
cl-lib because of that.

The compiler really needs cl-lib while running as needs to understand
user defined types (cl structs).

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

  Andrea