Re: Byte-compilation of custom themes

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <address@hidden>
> Cc: <address@hidden>,  <address@hidden>
> Date: Sun, 03 Jun 2018 17:08:22 +0100
> 
> 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?

In most sessions cl-lib is loaded pretty close to startup, so the
problem doesn't exist in practice, IMO.

> Why wouldn't we want the assertion to be exercised every time
> custom-available-themes is called?

Because it's complicated, and I don't see any reason to justify that
complication?

But this is not a string opinion, so we could just drop the issue and
move on.

Thanks.

> 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

Any reason you require cl-lib and not cl-macs?