bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Eli Zaretskii]

If you have some *.eln files in your ~/.emacs.d/eln-cache/ directory,
and the update from Git causes some of the corresponding *.el files to
be updated, then the *.elc files are rebuilt, but the *.eln files are
not.  Which then leaves you with stale *.eln files in the cache.

Can the FOO.eln file be re-generated if the corresponding FOO.elc file
is being generated?

And I wonder what happens when we load the corresponding library: will
the .eln file be preferred even if it's outdated, or will we load the
.elc file in this situation?


In GNU Emacs 28.0.50 (build 29, i686-pc-mingw32)
 of 2021-03-13 built on HOME-C4E4A596F7
Repository revision: d018584814e0c15f13bc458ba54491239b584069
Repository branch: feature/native-comp
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-native-compilation
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp
comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq
byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process nativecomp emacs)

Memory information:
((conses 16 90692 11966)
 (symbols 48 8990 0)
 (strings 16 24701 4594)
 (string-bytes 1 748980)
 (vectors 16 16420)
 (vector-slots 8 306021 10401)
 (floats 8 29 49)
 (intervals 40 266 10)
 (buffers 888 11))

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> If you have some *.eln files in your ~/.emacs.d/eln-cache/ directory,
> and the update from Git causes some of the corresponding *.el files to
> be updated, then the *.elc files are rebuilt, but the *.eln files are
> not.  Which then leaves you with stale *.eln files in the cache.
>
> Can the FOO.eln file be re-generated if the corresponding FOO.elc file
> is being generated?

FOO.eln should be regenerated when FOO.elc is regenerated using make
*if* FOO.el is part of the files that are native compiled during the
build process (all files when using NATIVE_FULL_AOT).

If this is not what's going on we have a bug.

> And I wonder what happens when we load the corresponding library: will
> the .eln file be preferred even if it's outdated, or will we load the
> .elc file in this situation?

The .elc will be loaded and deferred compilation will spawn an async
native compilation + will do the hot definition swap.

Thanks

  Andrea

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 47120@debbugs.gnu.org
> Date: Sat, 13 Mar 2021 19:43:55 +0000
> 
> > Can the FOO.eln file be re-generated if the corresponding FOO.elc file
> > is being generated?
> 
> FOO.eln should be regenerated when FOO.elc is regenerated using make
> *if* FOO.el is part of the files that are native compiled during the
> build process (all files when using NATIVE_FULL_AOT).
> 
> If this is not what's going on we have a bug.

I'm talking about the *.el files that are not automatically natively
compiled, they are natively compiled when first time loaded into
Emacs.

> > And I wonder what happens when we load the corresponding library: will
> > the .eln file be preferred even if it's outdated, or will we load the
> > .elc file in this situation?
> 
> The .elc will be loaded and deferred compilation will spawn an async
> native compilation + will do the hot definition swap.

That's OK.  But I think it would be better to recompile the .eln file
when .el is updated and we are byte-compiling to produce an updated
.elc file.

Thanks.

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47120@debbugs.gnu.org
>> Date: Sat, 13 Mar 2021 19:43:55 +0000
>> 
>> > Can the FOO.eln file be re-generated if the corresponding FOO.elc file
>> > is being generated?
>> 
>> FOO.eln should be regenerated when FOO.elc is regenerated using make
>> *if* FOO.el is part of the files that are native compiled during the
>> build process (all files when using NATIVE_FULL_AOT).
>> 
>> If this is not what's going on we have a bug.
>
> I'm talking about the *.el files that are not automatically natively
> compiled, they are natively compiled when first time loaded into
> Emacs.

I see now thanks, but I'm wondering why should we native compile it
automatically when the .el is updated later-on if we don't do it during
the first build?

Thanks

  Andrea

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 47120@debbugs.gnu.org
> Date: Sat, 13 Mar 2021 20:12:41 +0000
> 
> > I'm talking about the *.el files that are not automatically natively
> > compiled, they are natively compiled when first time loaded into
> > Emacs.
> 
> I see now thanks, but I'm wondering why should we native compile it
> automatically when the .el is updated later-on if we don't do it during
> the first build?

It just doesn't sound right to me not to update.

But maybe others will think differently.

Or maybe we should by default native-compile all the *.el files in the
tarball as part of the build, and then what I expect will happen
automatically.

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47120@debbugs.gnu.org
>> Date: Sat, 13 Mar 2021 20:12:41 +0000
>> 
>> > I'm talking about the *.el files that are not automatically natively
>> > compiled, they are natively compiled when first time loaded into
>> > Emacs.
>> 
>> I see now thanks, but I'm wondering why should we native compile it
>> automatically when the .el is updated later-on if we don't do it during
>> the first build?
>
> It just doesn't sound right to me not to update.
>
> But maybe others will think differently.
>
> Or maybe we should by default native-compile all the *.el files in the
> tarball as part of the build, and then what I expect will happen
> automatically.

Yeah, I guess if we go for distributing a tarball with .eln files would
be nice to compile as mush as possible to save computation time to the
user.  That said I like the general idea of keeping the behavior of
following builds symmetric with the initial one.

Regards

  Andrea

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 47120@debbugs.gnu.org
> Date: Sat, 13 Mar 2021 20:26:39 +0000
> 
> > Or maybe we should by default native-compile all the *.el files in the
> > tarball as part of the build, and then what I expect will happen
> > automatically.
> 
> Yeah, I guess if we go for distributing a tarball with .eln files would
> be nice to compile as mush as possible to save computation time to the
> user.  That said I like the general idea of keeping the behavior of
> following builds symmetric with the initial one.

OK, then feel free to close this issue.

bug#47120: 28.0.50; [feature/native-comp] Stale *.eln files are not recompiled

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47120@debbugs.gnu.org
>> Date: Sat, 13 Mar 2021 20:26:39 +0000
>> 
>> > Or maybe we should by default native-compile all the *.el files in the
>> > tarball as part of the build, and then what I expect will happen
>> > automatically.
>> 
>> Yeah, I guess if we go for distributing a tarball with .eln files would
>> be nice to compile as mush as possible to save computation time to the
>> user.  That said I like the general idea of keeping the behavior of
>> following builds symmetric with the initial one.
>
> OK, then feel free to close this issue.

Done thanks

  Andrea