emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Byte-compilation of custom themes


From: Basil L. Contovounesios
Subject: Re: Byte-compilation of custom themes
Date: Sun, 03 Jun 2018 17:08:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: "Basil L. Contovounesios" <address@hidden>
>> Cc: <address@hidden>, Eli Zaretskii <address@hidden>
>> Date: Sun, 03 Jun 2018 12:21:07 +0100
>> 
>> You're right, emacs -Q followed by (fboundp 'cl-assert) returns nil.
>> 
>> > I think the confusing comes from help-fns.el which does (require
>> > 'cl-lib), so if you do `C-h f cl-assert RET` it will indeed tell you
>> > it's autoloaded, but it's just because `C-h f` ended up requiring
>> > cl-lib.
>> 
>> No, the confusion comes from looking at the source of cl-macs.el, in
>> which cl-assert is given an ;;;###autoload cookie.  I see now that there
>> are some comments in cl-lib.el that suggest loading cl-loaddefs.el
>> involves some trickery, so I guess I don't get to eat the cake here.
>> 
>> In that case, I don't see how Eli's suggestion to predicate the
>> cl-assert call on (featurep 'cl-lib) will help, as feauturep is not
>> going to load the library for us.
>
> ??? I meant the following obvious trick:
>
>   (if (featurep 'cl-lib)
>       (cl-assert ....))
>
> Am I missing something?

I understood what you meant, but not what this is supposed to do or
protect against.  You see, 'make bootstrap' fails not when there is an
ungaurded call to cl-assert in custom-available-themes, but when there
is a top-level (require 'cl-lib) in custom.el.

So, if we can't load cl-lib at the top-level of custom.el, and we don't
load cl-lib in custom-available-themes, then the featurep check says
"only call cl-assert if some other library has already loaded cl-lib for
us", which doesn't make sense to me.  What is the benefit of
conditionally calling an assertion at runtime?  Why wouldn't we want the
assertion to be exercised every time custom-available-themes is called?

Just to be clear, including any one of the following three top-level
forms in custom.el breaks 'make bootstrap', irrespective of the NOERROR
argument passed to require, and even when there is no subsequent mention
of cl-assert or any other cl-lib feature in custom.el:

(require 'cl-lib)
(eval-when-compile (require 'cl-lib))
(when t (require 'cl-lib))

In all three cases, 'make bootstrap' reports the following:

Loading custom (source)...
Warning: Unknown defun property ‘gv-setter’ in cl-fifth
Warning: Unknown defun property ‘gv-setter’ in cl-sixth
Warning: Unknown defun property ‘gv-setter’ in cl-seventh
Warning: Unknown defun property ‘gv-setter’ in cl-eighth
Warning: Unknown defun property ‘gv-setter’ in cl-ninth
Warning: Unknown defun property ‘gv-setter’ in cl-tenth
Symbol’s function definition is void: gv-define-simple-setter
Makefile:745: recipe for target 'bootstrap-emacs' failed

I hope I've clarified the source of my confusion and apologise if I'm
missing something obvious.

Thanks,

-- 
Basil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]