GNU bug report logs - #77469
finder-inf is not autocompiled on installation

Previous Next

Full log

Message #26 received at 77469 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 05 Apr 2025 18:44:53 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Sat, 5 Apr 2025 16:16:22 +0200
> Cc: 77469 <at> debbugs.gnu.org
> 
> > I hear you, but OTOH compiling this file will make the build a tad
> > longer, so it is not coming for free.
> >
> > In general, we don't compile files that have no code.
> 
> Yes, now I understand this much better, and that there is no point in
> byte-compilation.
> 
> Although adding a coding: ascii (or coding: utf-8) declaration at top
> would help a little bit, as discussed in
> https://github.com/nilcons/emacs-research/tree/master/parse-speed-byte-compile

This shouldn't be necessary, since file-coding-system-alist already
says that *.el files should be decoded as UTF-8.

> I also looked into your statement of "In general, we don't compile
> files that have no code", because I was wondering how come that this
> is the only file that trips up my elc only dotemacs startup scenario
> and not the other files that you refer to.
> 
> What I found is that the other files (e.g. subdirs.el) are loaded by
> explicitly specifying ".el" extension on load.  Could we do that for
> this case?  Is that an acceptable compromise to not make the build
> slower, but solve my issue?

I'll let others comment on that, I'm not sure I understand well enough
the implications for package.el.

> Should we also include the "coding: ascii" on top of the file to make
> loading faster?

Shouldn't be necessary, see above.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.