Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Cc: spwhitton@spwhitton.name, rlb@defaultvalue.org,
>  monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org,
>  akrl@sdf.org
> Date: Sun, 23 Oct 2022 19:08:23 +0200
> 
> > Please tell the details: which files are being compiled, and whether
> > do you see the corresponding *.eln files in the eln-cache afterwards.
> > Once a .eln file is in the eln-cache, the next invocation should not
> > re-compile the same file, it should load the compiled .eln file from
> > the eln-cache.
> 
> perhaps I misinterpreted and what I saw was the testing of
> the .eln cache?:
> 
> I did
> 
> find "/home/grfz/.config/emacs/eln-cache/" 
> "/home/grfz/src/emacs-master-next/native-lisp/" -type f | xargs -r ls -Altr > 
> /tmp/before
> 
> <start Emacs again>
> 
> while sleep 1 ; do ps -eo pid,tty,stat,user,group,etime,time,cgroup,args  fax 
> >> faxme; done  # while emacs started
> 
> find "/home/grfz/.config/emacs/eln-cache/" 
> "/home/grfz/src/emacs-master-next/native-lisp/" -type f | xargs -r ls -Altr > 
> /tmp/before
                                                ^^^^^^
I guess you mean "after", not "before"?

> But file faxme contains 280 lines like this:
> 
> /home/grfz/src/emacs-master-next/src/emacs --batch -l 
> /tmp/emacs-async-comp-cl-lib-7Go9da.el

And there's already a cl-lib-XXXXX.eln file under eln-cache?

> 0 grfz@no:/tmp$ grep -o 'emacs-async-comp-.*' faxme | cut -d - -f 4- | sed -e 
> "s/-[^-]*\.el$//" |sort -u | while read ; do grep -qs $REPLY before || echo 
> $REPLY; done
> 0 grfz@no:/tmp$
> 
> 
> So all these "emacs-async-comp-cl-lib-7Go9da.el" like files
> have corresponding files in the .eln cache.
> 
> Is it possible that it takes 150 secs to test the .eln cache?

"Test" in what sense?  Who do you think needs to "test" the cache?

Anyway, the above is not what I meant.  You present some commands and
scripts, and expect me to guess what happens by showing only their
results.  It's very hard to analyze a problem that way.

Instead, please do this:

  . find the latest subdirectory of the eln-cache whose name is
    29.0.5-XXXX (where XXXX is some hash) and list is contents
  . start Emacs
  . use 'top' or similar command to see if async compilations are
    running which were started by Emacs you run above
  . compare the files these async compilations are compiling with what
    you see in that latest subdirectory of eln-cache
  . show the list of files that were compiled although they already
    had corresponding *.eln files in that subdirectory
  . let the compilations run to completion (use 'top' to see when
    there are no more compilations running)
  . look in the *Async-native-compile-log* buffer to see if there are
    any warning or error messages there; if there are, post them
  . kill Emacs
  . look into that subdirectory of the eln-cache and see whether there
    are any new *.eln files in it as result of the compilation

One reason why Emacs could keep compiling files that already have
*.eln files in the cache is because the existing *.eln files are
outdated or incompatible with the Emacs binary.  This happens a lot if
you are using the master branch, because we make significant changes
there frequently, and they require recompilation.  You will in those
cases see *.eln files whose base names are the same, but the hashes
are different.