GNU bug report logs -
#74368
31.0.50; Different warnings between native-compile and native-compile-async
Previous Next
Reported by: Sean Devlin <spd <at> toadstyle.org>
Date: Fri, 15 Nov 2024 17:06:01 UTC
Severity: normal
Tags: notabug
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Sean Devlin <spd <at> toadstyle.org> writes:
> Hi folks,
>
> I'm not sure if this is a bug, but I noticed a difference in behavior
> when compiling with native-compile and native-compile-async.
>
> Recipe:
>
> 1. mkdir /tmp/emacs-test
> 2. printf ";; -*- lexical-binding: t; -*-\n\n(vertico-mode)\n" > /tmp/emacs-test/test.el
> 2. HOME=/tmp/emacs-test emacs
> 3. M-x package-install RET vertico RET
> 4. M-: (native-compile "/tmp/emacs-test/test.el") RET
> 5. M-! touch /tmp/emacs-test/test.el RET
> 6. M-: (native-compile-async "/tmp/emacs-test/test.el") RET
>
> There is no warning when compiling synchronously, but there is a warning
> during asynchronous compilation:
>
> test.el:3:2: Warning: the function ‘vertico-mode’ is not known to be
> defined.
>
> I guess maybe the asynchronous compiler has not processed the autoloads
> from installed packages, whereas the synchronous compiler has.
>
> Is this difference in behavior expected? Or is one of the compilers
> behaving incorrectly?
>
> Thanks!
Hi Devlin,
yes this difference is expected, 'native-compile' runs the compilation
in the loaded Emacs so that all the definitions of loaded packages are
known to the compiler. 'native-compile-async' runs in a new fresh Emacs
so all requires need to be there in the compilation unit in order to let
the compiler be able to load the definitions.
We have also some doc in (info "(elisp) Native-Compilation Variables")
which goes like this:
A common cause for asynchronous native-compilation to produce
warnings is compiling a file that is missing some ‘require’ of a
necessary feature. The feature may be loaded into the main emacs,
but because native compilation always starts from a subprocess with
a pristine environment, that may not be true for the subprocess.
Regards
Andrea
This bug report was last modified 235 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.